サーバー名とは異なるデフォルトのインスタンス名
新しいギグを始めたところ、Core Server 2012 R2にインストールされているSQL 2012（SP2）の2つのインスタンスが、実行しているサーバーとは異なる名前を持っていることがわかりました。どちらも仮想サーバーです。たとえば、サーバー名はServer2およびServer3（RDPが可能で、この名前を使用して複数の方法でサーバーに接続できます）で、他のマシンからSSMSに接続することもできます。ただし、@@ Servernameを実行すると、両方のサーバーで "CO-SQLTEMPLATE"が返されます。これが厄介な理由は、これらの2つのインスタンスがAlwaysOnレプリケーションに参加し、いくつかの問題があるためです...最も目立つものは自動バックアップが機能しないことです。 HADRのsystablesと関数を使用すると、「プライマリ」であるレプリカがないか、またはすべてがレプリカであることが示されます（!!!）。また、レプリケーションが実際に機能していることも明らかではありません。いくつかのAGで、データベースがプライマリ（Server1）と同期されていることを示していますが、本質的に同じ名前のインスタンスが2つあるため、これは信頼できません。
私はGoogleを探し回っていますが、インストール中にSQL Serverがインスタンス名を取得する場所を示すソースが見つかりません。この問題は今まで見たことがなく、本当に奇妙です。
これは、2つのサーバーを完全に消去してゼロから開始する前に、解決策を見つけようとする私の最後の溝です（明らかに、私はむしろそうしません）。
「頼りになる」SQL Serverを作成するのは簡単だと誰かが思ったように思えますVMクローンできます。標準のCO-SQLTEMPLATE SQL Server名を変更することに煩わされる人はいません。レプリケーションがSQL Server名がVM /物理サーバー名と一致する必要があるため（インスタンスを除いて）、正常に機能しているかどうかを質問します。さらに悪いことに、人々はおそらくVM /物理名を使用してSQL Serverに接続していて、 CO-SQLTEMPLATEについて知っている。
ゴミ箱に入れて再構築しない場合は、SQL Serverの名前を、それがインストールされているWindows Serverの名前と一致するように変更することをお勧めします。
exec sp_dropserver 'CO-SQLTEMPLATE'
exec sp_addserver 'MyWIndowsServerName'.
SQL Serverのセットアップは信用できません。可能であれば、可用性グループフォルダーをチェックして、レプリケートされたデータベースがmyDB（プライマリ）またはmyDB（セカンダリ）を示しているかどうかを確認します。次に、myDB（プライマリ）を使用するサーバーで、AlwaysOnレプリケーションを中断して再構築し、AlwaysOnウィザードを使用してレプリケーションを再構築します。 （ただし、ウィザードにはリスナーを追加しません。その部分はバグがあるようです。リスナーを個別に追加します）。
しかし、その前に、サーバーがあなたの言うほど混乱している場合は、Windowsクラスターがフェールオーバーマネージャーを介して適切に機能していることも確認します。そして、DNSが実際にWindowsサーバーとリスナー（および場合によっては目撃者）の名前を含んでいることを確認します（ある場合）。
注意：サーバーは、2つの異なるサーバー上のCO-SQLTEMPLATEの両方のインスタンスに接続するユーザーが想像したよりもさらに悪い可能性があります。どちらも2つの完全に異なるデータセットを表し、まったく関係がないためです。結局のところ、彼らは便利なダンディVM=テンプレートを使用して、SQL Serverのライフを容易にするためです。