Always On AGがロックしたのはなぜですか？
私はここで頭の中にいます。 tl; dr;圧縮ファイルを実行しました（わかっています、知っています）（10 GBの空き領域を含む100 GBのファイルを2 GBずつ圧縮します）。15分ほど実行すると、すべてが壊れました。私が理解できないこと、なぜすべてが壊れたのですか？同期AlwaysOn可用性グループには2つのサーバーがあります。 SQL Server 2014 SP1。サーバー2012 r2。プライマリがログメッセージRemote harden of transaction 'user_transaction' (ID 0x000000887e6bc779 0000:002ede71) started at Mar 13 2018 4:20PM in database 'AAAA' at LSN (296:17783:1) failed.でトランザクションの拒否を開始しました
単一のデータベースでのshrinkfile操作がセカンダリのすべての単一のデータベースをロックするのはなぜですか？最初に試みたのは、セカンダリSQLインスタンスを再起動することでした。これは効果がありませんでした。
AGからデータベースを削除すると（ALTER REMOVE DATABASE）、その特定のデータベースでトランザクションを再開できました。これにより、データベースがセカンダリでRESTORING状態のままになります。データベースをAGに戻そうとして、最新のtxログバックアップをセカンダリに適用しようとしました。セカンダリは、LSNが一致しないというエラーでtxログバックアップを拒否しました。残念ながら特定のメッセージは書き留めませんでしたが、「以前のtxバックアップを復元する必要がある」という単純なメッセージではありませんでした。私たちはそれにtxログのバックアップを与えていました。それは30秒間スピンしてからエラーになります。
メモのプライマリログエントリ
2018-03-13 16:45:05.650 Backup BACKUP failed to complete the command
BACKUP LOG AAAA. Check the backup application log for detailed messages.
2018-03-13 16:42:34.830 spid40s A connection for availability group
'SQLDB' from availability replica 'SQLDB02' with id
[90C6C7E0-E41B-45D6-92D0-1CDCD33F49BF] to 'SQLDB03' with id
[659B20D9-F54D-4CE3-A492-B1CFD4D9BC22] has been successfully established. This
is an informational message only. No user action is required.
(we restarted the secondary sql service) 2018-03-13 16:42:08.820 spid28s
A connection timeout has occurred on a previously established connection to
availability replica 'SQLDB03' with id [659B20D9-F54D-4CE3-A492-B1CFD4D9BC22].
Either a networking or a firewall issue exists or the availability replica has
transitioned to the resolving role.
2018-03-13 16:27:40.670 BACKUP failed to complete the command BACKUP LOG AAAAA.
Check the backup application log for detailed messages.
2018-03-13 16:22:18.900 DBCC SHRINKFILE for file ID 1 is waiting for the
snapshot transaction with timestamp 22194769242 and other snapshot transactions
linked to timestamp 22194769242 or with timestamps older than 22194835703 to
finish.
2018-03-13 16:21:13.460 A connection for availability group 'SQLDB' from
availability replica 'SQLDB02' with id [90C6C7E0-E41B-45D6-92D0-1CDCD33F49BF]
to 'SQLDB03' with id [659B20D9-F54D-4CE3-A492-B1CFD4D9BC22] has been
successfully established. This is an informational message only. No user
action is required.
2018-03-13 16:21:13.390 The state of the local availability replica in
availability group 'SQLDB' has changed from 'PRIMARY_PENDING' to
'PRIMARY_NORMAL'. The state changed because the local replica has completed
processing Online command from Windows Server Failover Clustering (WSFC). For
more information, see the SQL Server error log, Windows Server Failover
Clustering (WSFC) management console, or WSFC log.
2018-03-13 16:21:13.310 AlwaysOn: The local replica of availability group
'SQLDB' is preparing to transition to the primary role in response to a request
from the Windows Server Failover Clustering (WSFC) cluster. This is an
informational message only. No user action is required.
2018-03-13 16:20:55.550 (x 50) AlwaysOn Availability Groups connection with
secondary database terminated for primary database '' on the availability
replica '' with Replica ID: {659b20d9-f54d-4ce3-a492-b1cfd4d9bc22}. This is an
informational message only. No user action is required.
2018-03-13 16:20:55.540 (x 1000) The client was unable to reuse a session with
SPID 276, which had been reset for connection pooling. The failure ID is 46.
This error may have been caused by an earlier operation failing. Check the
error logs for failed AAAA immediately before this error message.
3/13/2018 4:20:44 PM: The state of the local availability replica in
availability group 'SQLDB' has changed from 'PRIMARY_NORMAL' to
'RESOLVING_NORMAL'
3/13/2018 4:20:44 PM: AlwaysOn: The local replica of availability group 'SQLDB'
is preparing to transition to the resolving role in response to a request from
the Windows Server Failover Clustering (WSFC) cluster. This is an informational
message only. No user action is required.
3/13/2018 4:17:07 PM DBCC SHRINKFILE for file ID 1 is waiting for the snapshot
transaction with timestamp 22194769242 and other snapshot transactions linked
to timestamp 22194769242 or with timestamps older than 22194835703 to finish.
注記の二次ログエントリ
2018-03-13 17:02:00.990 spid63s The database 'AAAA' is marked RESTORING
and is in a state that does not allow recovery to be run.
2018-03-13 17:02:00.980 spid63s Starting up database 'AAAA'.
2018-03-13 17:02:00.970 spid63s State information for database 'AAAA' -
Hardended Lsn: '(2665414:190311:1)' Commit LSN: '(2665414:190298:27)'
Commit Time: 'Mar 13 2018 4:20PM'
2018-03-13 17:02:00.940 spid63s State information for database 'AAAA' -
Hardended Lsn: '(2665414:190311:1)' Commit LSN: '(2665414:190298:27)'
Commit Time: 'Mar 13 2018 4:20PM'
2018-03-13 17:02:00.810 spid63s Nonqualified transactions are being rolled back
in database AAAA for an AlwaysOn Availability Groups state change. Estimated
rollback completion: 100%. This is an informational message only. No user
action is required.
2018-03-13 17:02:00.810 spid112s AlwaysOn Availability Groups connection
with primary database terminated for secondary database 'AAAA' on the
availability replica 'SQLDB02' with Replica ID:
{90c6c7e0-e41b-45d6-92d0-1cdcd33f49bf}. This is an informational message only.
No user action is required.
この時点で、プライマリからAGからAAAAを削除します。 （4:43ではなく5:02）
2018-03-13 16:43:22.760 Logon Error: 976, Severity: 14, State: 1.
2018-03-13 16:43:22.760 Logon The target database, 'AAAA', is participating
in an availability group and is currently not accessible for queries. Either
data movement is suspended or the availability replica is not enabled for read
access. To allow read-only access to this and other databases in the
availability group, enable read access to one or more secondary availability
replicas in the group. For more information, see the ALTER AVAILABILITY GROUP
statement in SQL Server Books Online.
2018-03-13 16:42:02.740 spid27s CHECKDB for database 'AAAA' finished without
errors on 2018-02-24 23:18:46.247 (local time). This is an informational
message only; no user action is required.
2018-03-13 16:42:02.690 spid27s Recovery completed for database AAAA
(database ID 6) in 26 second(s) (analysis 38 ms, redo 1040 ms, undo 0 ms.) This
is an informational message only. No user action is required.
2018-03-13 16:42:02.650 spid27s 5977 transactions rolled forward in database
'AAAA' (6:0). This is an informational message only. No user action is
required.
2018-03-13 16:41:34.400 spid27s State information for database 'AAAA' -
Hardended Lsn: '(0:0:0)' Commit LSN: '(0:0:0)' Commit Time: 'Jan 1 1900
12:00AM'
2018-03-13 16:41:34.400 spid50s AlwaysOn Availability Groups connection with
primary database terminated for secondary database 'AAAA' on the availability
replica 'SQLDB02' with Replica ID: {90c6c7e0-e41b-45d6-92d0-1cdcd33f49bf}. This
is an informational message only. No user action is required.
2018-03-13 16:41:34.400 spid27s State information for database 'AAAA' -
Hardended Lsn: '(0:0:0)' Commit LSN: '(0:0:0)' Commit Time: 'Jan 1 1900
12:00AM'
2018-03-13 16:41:34.390 spid27s Nonqualified transactions are being rolled back
in database AAAA for an AlwaysOn Availability Groups state change. Estimated
rollback completion: 100%. This is an informational message only. No user
action is required.
2018-03-13 16:41:34.110 spid22s The state of the local availability replica in
availability group 'SQLDB' has changed from 'NOT_AVAILABLE' to
'RESOLVING_NORMAL'. The state changed because the local instance of SQL Server
is starting up. For more information, see the SQL Server error log, Windows
Server Failover Clustering (WSFC) management console, or WSFC log.
2018-03-13 16:41:34.100 Server The SQL Server Network Interface library could
not register the Service Principal Name (SPN) [ MSSQLSvc/$DB.$DOMAIN ] for the
SQL Server service. Windows return code: 0x2098, state: 15. Failure to register
a SPN might cause integrated authentication to use NTLM instead of Kerberos.
This is an informational message. Further action is only required if Kerberos
authentication is required by authentication policies and if the SPN has not
been manually registered.
...normal startup stuff.
2018-03-13 16:41:09.050 spid9s SQL Server is terminating in response to a
'stop' request from Service Control Manager. This is an informational message
only. No user action is required.
2018-03-13 16:20:43.880 (x 50) spid169s AlwaysOn Availability Groups connection
with primary database terminated for secondary database 'AAAA' on
the availability replica 'SQLDB02' with Replica ID:
{90c6c7e0-e41b-45d6-92d0-1cdcd33f49bf}. This is an informational message only.
No user action is required.
2018-03-13 16:20:43.880 (x 50) spid169s AlwaysOn Availability Groups connection
with primary database terminated for secondary database 'AAAA' on
the availability replica 'SQLDB02' with Replica ID:
{90c6c7e0-e41b-45d6-92d0-1cdcd33f49bf}. This is an informational message only.
No user action is required.
2018-03-13 16:20:43.880 (x 50) spid170s The availability group database
"AAAA" is changing roles from "SECONDARY" to "RESOLVING" because
the mirroring session or availability group failed over due to role
synchronization. This is an informational message only. No user action is
required.
2018-03-13 11:57:34.050 spid106 Server process ID is 2268.
なぜすべてが壊れたのですか？
ご提供いただいたキュレートされたエラーログ出力に基づいて、shrinkfileは現在開いているスナップショットトランザクションが完了するのを待っていました。
2018年3月13日4:17:07 PMファイルID 1のDBCC SHRINKFILEは、タイムスタンプ22194769242およびタイムスタンプ22194769242にリンクされた他のスナップショットトランザクション、または22194835703より古いタイムスタンプを持つスナップショットトランザクションを待機しています仕上げます。
同じトランザクションのタイムスタンプを持つ別のエントリが後であるため、しばらくの間この方法でスタックしていることはかなり確実です。
最初にログに記録されたメッセージの後に、私たちは...
2018年3月13日4:20:44 PM：AlwaysOn：可用性グループ「SQLDB」のローカルレプリカは、Windows Serverフェールオーバークラスタリング（WSFC）クラスターからの要求に応答して、解決ロールに移行する準備をしています。これは情報メッセージです。ユーザーの操作は必要ありません。
何が起こったのかを確認するには、クラスターログを確認する必要があります。その他の使用ログは、ログフォルダー内のsp_server_diagnosticsの出力、フェイルオーバーポリシーレベル、および場合によっては常時稼働の拡張イベントファイルです。
ログの強化に関する問題も発生し始めました。
LSN（296：17783：1）のデータベース 'AAAA'で2018年3月13日4:20 PMに開始されたトランザクション 'user_transaction'（ID 0x000000887e6bc779 0000：002ede71）のリモート強化は失敗しました。
なぜこれが起こったのかは言えませんが、プライマリーを残すべきだったのはかなり不安定な状態です。
単一のデータベースでのshrinkfile操作がセカンダリのすべての単一のデータベースをロックするのはなぜですか？
単一のデータベースのエラーメッセージと問題しか表示されないため、なぜ「すべてのデータベースをロックアップする」のかはわかりません。データベースファイルのEXラッチを保持している長時間実行の縮小ファイルが縮小されると、最終的に問題が発生すると予想されます。十分な時間が与えられました。
残念ながら、何が起こったのかについて有効な仮定を与えるのに十分なデータはありませんが、少なくともこれは調査/調査するためのいくつかのことを提供します。