Merge pull request #21058 from MicrosoftDocs/FromPublicRepo

Confirm merge from FromPublicRepo to main to sync with https://github.com/MicrosoftDocs/sql-docs (branch live)

Author: huypub

docs/connect/odbc/linux-mac/known-issues-in-this-version-of-the-driver.md

@@ -68,7 +68,17 @@ UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
 ```  
 
 There is more than one Driver Manager installed and your application is using the wrong one, or the Driver Manager was not built correctly.  
-  
+
+Some users encounter the following issue: `OperationalError: ('08001', '[08001] [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)')`. The error is related to the version of OpenSSL that macOS uses. OpenSSL typically is installed through Brew, and it contains the openssl, openssl@1.1, and openssl@3 binaries. 
+
+To resolve this error, change the symlink of the openssl binary to openssl@1.1:
+
+```shell
+rm -rf /usr/local/opt/openssl
+version=$(ls /usr/local/Cellar/openssl@1.1 | grep "1.1")
+ln -s /usr/local/Cellar/openssl@1.1/$version /usr/local/opt/openssl
+```
+
 For more information about resolving connection failures, see:  
 
 - [Steps to troubleshoot SQL connectivity issues](/archive/blogs/sql_protocols/steps-to-troubleshoot-sql-connectivity-issues)  

docs/relational-databases/system-dynamic-management-views/sys-dm-hadr-database-replica-states-transact-sql.md

@@ -43,19 +43,19 @@ ms.author: wiassaf
 |**synchronization_health**|**tinyint**|Reflects the intersection of the synchronization state of a database that is joined to the availability group on the availability replica and the availability mode of the availability replica (synchronous-commit or asynchronous-commit mode), one of the following values.<br /><br /> 0 = Not healthy. The **synchronization_state** of the database is 0 (NOT SYNCHRONIZING).<br /><br /> 1 = Partially healthy. A database on a synchronous-commit availability replica is considered partially healthy if **synchronization_state** is 1 (SYNCHRONIZING).<br /><br /> 2 = Healthy. A database on an synchronous-commit availability replica is considered healthy if **synchronization_state** is 2 (SYNCHRONIZED), and a database on an asynchronous-commit availability replica is considered healthy if **synchronization_state** is 1 (SYNCHRONIZING).|  
 |**synchronization_health_desc**|**nvarchar(60)**|Description of the **synchronization_health** of the availability database.<br /><br /> NOT_HEALTHY<br /><br /> PARTIALLY_HEALTHY<br /><br /> HEALTHY|  
 |**database_state**|**tinyint**|0 = Online<br /><br /> 1 = Restoring<br /><br /> 2 = Recovering<br /><br /> 3 = Recovery pending<br /><br /> 4 = Suspect<br /><br /> 5 = Emergency<br /><br /> 6 = Offline<br /><br /> **Note:** Same as **state** column in sys.databases.|  
-|**database_state_desc**|**nvarchar(60)**|Description of the **database_state** of the availability replica.<br /><br /> ONLINE<br /><br /> RESTORING<br /><br /> RECOVERING<br /><br /> RECOVERY_PENDING<br /><br /> SUSPECT<br /><br /> EMERGENCY<br /><br /> OFFLINE<br /><br /> **Note:** Same as **state_desc** column in sys.databases.|  
+|**database_state_desc**|**nvarchar(60)**|Description of the **database_state** of the availability replica.<br /><br /> ONLINE<br /><br /> RESTORING<br /><br /> RECOVERING<br /><br /> RECOVERY_PENDING<br /><br /> SUSPECT<br /><br /> EMERGENCY<br /><br /> OFFLINE<br /><br /> **Note:** Same as `state_desc` column in sys.databases.|  
 |**is_suspended**|**bit**|Database state, one of:<br /><br /> 0 = Resumed<br /><br /> 1 = Suspended|  
 |**suspend_reason**|**tinyint**|If the database is suspended, the reason for the suspended state, one of:<br /><br /> 0 = User action<br /><br /> 1 = Suspend from partner<br /><br /> 2 = Redo<br /><br /> 3 = Capture<br /><br /> 4 = Apply<br /><br /> 5 = Restart<br /><br /> 6 = Undo<br /><br /> 7 = Revalidation<br /><br /> 8 = Error in the calculation of the secondary-replica synchronization point|  
 |**suspend_reason_desc**|**nvarchar(60)**|Description of the database suspended state reason, one of:<br /><br /> SUSPEND_FROM_USER = A user manually suspended data movement<br /><br /> SUSPEND_FROM_PARTNER = The database replica is suspended after a forced failover<br /><br /> SUSPEND_FROM_REDO = An error occurred during the redo phase<br /><br /> SUSPEND_FROM_APPLY = An error occurred when writing the log to file (see error log)<br /><br /> SUSPEND_FROM_CAPTURE = An error occurred while capturing log on the primary replica<br /><br /> SUSPEND_FROM_RESTART = The database replica was suspended before the database was restarted (see error log)<br /><br /> SUSPEND_FROM_UNDO = An error occurred during the undo phase (see error log)<br /><br /> SUSPEND_FROM_REVALIDATION = Log change mismatch is detected on reconnection (see error log)<br /><br /> SUSPEND_FROM_XRF_UPDATE = Unable to find the common log point (see error log)|  
-|**recovery_lsn**|**numeric(25,0)**|On the primary replica, the end of the transaction log before the primary database writes any new log records after recovery or failover. For a given secondary database, if this value is less than the current hardened LSN (last_hardened_lsn), recovery_lsn is the value to which this secondary database would need to resynchronize (that is, to revert to and reinitialize to). If this value is greater than or equal to the current hardened LSN, resynchronization would be unnecessary and would not occur.<br /><br /> **recovery_lsn** reflects a log-block ID padded with zeroes. It is not an actual log sequence number (LSN). For information about how this value is derived, see [Understanding the LSN Column Values](#LSNcolumns), later in this topic.|  
-|**truncation_lsn**|**numeric(25,0)**|On the primary replica, for the primary database, reflects the minimum log truncation LSN across all the corresponding secondary databases. If local log truncation is blocked (such as by a backup operation), this LSN might be higher than the local truncation LSN.<br /><br /> For a given secondary database, reflects the truncation point of that database.<br /><br /> **truncation_lsn** reflects a log-block ID padded with zeroes. It is not an actual log sequence number.|  
-|**last_sent_lsn**|**numeric(25,0)**|The log block identifier that indicates the point up to which all log blocks have been sent by the primary. This is the ID of the next log block that will be sent, rather than the ID of the most recently sent log block.<br /><br /> **last_sent_lsn** reflects a log-block ID padded with zeroes, It is not an actual log sequence number.|  
-|**last_sent_time**|**datetime**|Time when the last log block was sent.|  
-|**last_received_lsn**|**numeric(25,0)**|Log block ID identifying the point up to which all log blocks have been received by the secondary replica that hosts this secondary database.<br /><br /> **last_received_lsn** reflects a log-block ID padded with zeroes. It is not an actual log sequence number.|  
-|**last_received_time**|**datetime**|Time when the log block ID in last message received was read on the secondary replica.|  
-|**last_hardened_lsn**|**numeric(25,0)**|Start of the Log Block containing the log records of last hardened LSN on a secondary database.<br /><br /> On an asynchronous-commit primary database or on a synchronous-commit database whose current policy is "delay", the value is NULL. For other synchronous-commit primary databases, **last_hardened_lsn** indicates the minimum of the hardened LSN across all the secondary databases.<br /><br /> **Note: last_hardened_lsn** reflects a log-block ID padded with zeroes. It is not an actual log sequence number. For more information, see [Understanding the LSN Column Values](#LSNcolumns), later in this topic.|  
-|**last_hardened_time**|**datetime**|On a secondary database, time of the log-block identifier for the last hardened LSN (**last_hardened_lsn**). On a primary database, reflects the time corresponding to minimum hardened LSN.|  
-|**last_redone_lsn**|**numeric(25,0)**|Actual log sequence number of the last log record that was redone on the secondary database. **last_redone_lsn** is always less than **last_hardened_lsn**.|  
+|**recovery_lsn**|**numeric(25,0)**|On the primary replica, the end of the transaction log before the primary database writes any new log records after recovery or failover. For a given secondary database, if this value is less than the current hardened LSN (`last_hardened_lsn`), `recovery_lsn` is the value to which this secondary database would need to resynchronize (that is, to revert to and reinitialize to). If this value is greater than or equal to the current hardened LSN, resynchronization would be unnecessary and would not occur.<br /><br /> The `recovery_lsn` reflects a log-block ID padded with zeroes. It is not an actual log sequence number (LSN). For information about how this value is derived, see [Understanding the LSN Column Values](#LSNcolumns), later in this topic.|  
+|**truncation_lsn**|**numeric(25,0)**|On the primary replica, for the primary database, reflects the minimum log truncation LSN across all the corresponding secondary databases. If local log truncation is blocked (such as by a backup operation), this LSN might be higher than the local truncation LSN.<br /><br /> For a given secondary database, reflects the truncation point of that database.<br /><br /> `truncation_lsn` reflects a log-block ID padded with zeroes. It is not an actual log sequence number.|  
+|**last_sent_lsn**|**numeric(25,0)**|When querying the primary replica, `last_sent_lsn` is reported for each secondary replica database row. The log block identifier that indicates the point up to which all log blocks have been sent by the primary. This is the ID of the next log block that will be sent, rather than the ID of the most recently sent log block.<br /><br /> `last_sent_lsn` reflects a log-block ID padded with zeroes, It is not an actual log sequence number.|  
+|**last_sent_time**|**datetime**|When querying the primary replica, `last_sent_time` is reported for each secondary replica database row. Time when the last log block was sent.|  
+|**last_received_lsn**|**numeric(25,0)**|When querying a secondary replica, `last_received_lsn` is reported for the local secondary replica database row. Log block ID identifying the point up to which all log blocks have been received by the secondary replica that hosts this secondary database.<br /><br />The `last_received_lsn` reflects a log-block ID padded with zeroes. It is not an actual log sequence number.|  
+|**last_received_time**|**datetime**|When querying a secondary replica, `last_received_time` is reported for the local secondary replica database row. Time when the log block ID in last message received was read on the secondary replica.|  
+|**last_hardened_lsn**|**numeric(25,0)**|Start of the Log Block containing the log records of last hardened LSN on a secondary database.<br /><br /> On an asynchronous-commit primary database or on a synchronous-commit database whose current policy is "delay", the value is NULL. For other synchronous-commit primary databases, `last_hardened_lsn` indicates the minimum of the hardened LSN across all the secondary databases.<br /><br /> **Note:** the `last_hardened_lsn` reflects a log-block ID padded with zeroes. It is not an actual log sequence number. For more information, see [Understanding the LSN Column Values](#LSNcolumns), later in this topic.|  
+|**last_hardened_time**|**datetime**|On a secondary database, time of the log-block identifier for the last hardened LSN (`last_hardened_lsn`). On a primary database, reflects the time corresponding to minimum hardened LSN.|  
+|**last_redone_lsn**|**numeric(25,0)**|Actual log sequence number of the last log record that was redone on the secondary database. The `last_redone_lsn` is always less than **last_hardened_lsn**.|  
 |**last_redone_time**|**datetime**|Time when the last log record was redone on the secondary database.|  
 |**log_send_queue_size**|**bigint**|Amount of log records of the primary database that has not been sent to the secondary databases, in kilobytes (KB).|  
 |**log_send_rate**|**bigint**|Average rate at which primary replica instance sent data during last active period, in kilobytes (KB)/second.|