スキーマの変更は可用性グループを「破壊」しますか、それとも透過的に処理されますか？

私の組織はSQL Server 2012可用性グループの採用を計画しており、それがアプリケーションのアップグレードプロセスに与える影響（ある場合）を理解しようとしています。

私たちは8週間のサイクルでアプリケーションの更新をリリースします。どのリリースにもスキーマの変更やデータの移行が含まれる可能性があります。

私が理解しようとしているのは、HA / DRソリューションがスキーマの変更を透過的に処理する（新しい列、インデックスがセカンダリに追加される）かどうか、または各インスタンスでスキーマを作成してからAlways Onをオンに戻すために手動で介入する必要があるかどうかです。

私が想定しているデータ移行の部分は透過的に処理されますが、それも確認したいと思います。

また、可用性グループの構成に基づいてこれらの動作に違いはなく、誤っている可能性もないと全面的に想定しています。私にお知らせください。

一言で言えば; アプリケーションの特定のリリースでは、非常に大きなテーブル（数千から数億のレコード）に列を追加することで、テーブルを変更できます。一部の列は「完全に新しい」ため、Enterprise Onlineのスキーマ変更機能を利用できます。他の列は既存の列のリファクタリングである可能性があり（FullNameはFirstNameとLastNameに分割されます）、これらのフィールドに入力するために、テーブルの各行に対して移行が実行されます。これらの動作のいずれかでは、DBAがAlwaysOn構成を変更する必要がありますか、それともデフォルトで処理され、すべてのセカンダリがDDLおよびDMLステートメントを「無料」で取得しますか？

あなたが提供できる明確さをありがとう。

スキーマの変更とデータの変更は基本的に同じです。これは、今日の従来のミラーリングのように機能します。プライマリでのログで発生したことがセカンダリで発生します。ベガスで起こるすべてがベガスに留まる必要はありません。:-)

注意が必要なのは、プライマリをポイントするアプリケーションがあり、それをスキーマの変更に合わせて更新する場合です。ただし、セカンダリを指す別のアプリケーション（たとえば、読み取り専用インテント）があり、そのアプリの変更も同期する必要がある場合があります。

もう1つの問題は、可用性グループの一部であるデータベースが他のデータベース内のオブジェクトへの参照を持っている場合です（たとえば、ユーティリティデータベースに格納されている静的参照テーブル）。それらの変更があり、AGがそれらのオブジェクトに依存している場合は、それらの変更を手動でプッシュする必要があります。同じことが、ジョブ、サーバーレベルのログイン、リンクサーバーなどにも当てはまります。データベースの外部に存在するものや、トランザクション可能でないもの、あるいはその両方です。データベースユーザーは孤立する可能性があります（包含ユーザーは別として）。私はこれがおそらく明白であることを知っていますが、完全を期すために明示的にリストしたかったのです。

Remusからの回答が増えると、ユーザーはセカンダリレプリカのクエリを削除して、次のテーブルでREDOキューサイズのステータスを確認するように求めています。sys.dm_hadr_database_replica_statesAlwaysOn DDLとスキーマの変更