スキーマの変更は可用性グループを「破壊」しますか、それとも透過的に処理されますか？
私の組織は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_states AlwaysOn DDL and Schema Changes