タグ: SQL Server

  • SQL Server 2005から SQL Server 2019へのリンクサーバーの接続ができた

    前回、SQL Server 2019からSQL Server 2005へのリンクサーバーでの接続ができたので、今度はその逆を試した。Windows Server 2003の上のSQL Server 2005から、Windows Server 2022の上のSQL Server 2019に対して、リンクサーバーの設定をしたところ、接続でき、データの参照もできた。

    リンクサーバーの設定のとき、接続は「SQL Server」を選択して、接続した。

  • SQL Server 2019からSQL Server 2005へのリンクサーバーの接続ができた

    Windows Server 2022にインストールしたSQL Server 2019から、Windows Server 2003のSQL Server 2005に対して、リンクサーバーの設定を行ったところ、接続できた。

    SQL Server 2019から、リンクサーバー経由で、SQL Server 2005のテーブルの参照(Select)も更新(Update)もできた。SQL Server 2005はサポート終了しているので、マイクロソフトのサポート外だが。それにしても、SQL Server 2019からSQL Server 2005に接続とは、下位互換性が高い。本当に。

    SQL Server 2019からSQL Server 2005へのリンクサーバーの設定は、SQL Server Management Studioから「サーバーオブジェクト」の「リンクサーバー」を選択して、右クリックから「新しいリンクサーバー」で作成した。作成時、プロバイダーは「SQL Server Native Client 11.0」を選択した。これだけで繋げるのだから、楽である。

  • SQL ServerがインストールされたサーバをP2Vしたら起動時にイベントログにエラーが記録される

    イベントログに記録されていたログは下記。

    イベントID 455
    ソース ESENT
    msmdsrv (1400) ログ ファイル C:\Windows\system32\LogFiles\Sum\Api.log を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。
    
    イベントID 489
    ソース ESENT
    msmdsrv (1400) 読み取るためにファイル "C:\Windows\system32\LogFiles\Sum\Api.log" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。
    
    イベントID 490
    ソース ESENT
    msmdsrv (1400) 読み取りまたは書き込みのためにファイル "C:\Windows\system32\LogFiles\Sum\Api.chk" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。

    このエラーは、「C:\Windows\system32\LogFiles\Sum」のRead/Writeのアクセス権がないため、SQL Serverの起動時にログのフォルダを参照できずにエラーが記録されている。

    対応方法は下記。

    1. SQL Serverを実行しているユーザをサービスから調べる。

    2. 「C:\Windows\system32\LogFiles\Sum」のプロパティを開き、セキュリティからユーザを追加し、Read/Writeの権限を付ける。権限を付けるユーザが見つからない場合は、セキュリティを緩めた

    3. Windowsを再起動して、同じログがでるかを確認する。

    これで完了。

  • SQL Serverでプロシージャーの実行がエラーになる

    SQL Serverのプロシージャーの実行権限は、プロシージャーごとに、ロールまたはユーザに対して権限を付与する必要がある。権限を付与しておかないと、プロシージャーの実行ができない。(すっかり忘れていた)

    SQL Server Management Studioを使っている場合は、該当のプロシージャーを選択して、プロパティを開いて、権限の部分で、ユーザやロールを指定して、権限を付与する。

    https://docs.microsoft.com/ja-jp/sql/relational-databases/stored-procedures/grant-permissions-on-a-stored-procedure?view=sql-server-ver15

  • SQL ServerでViewの作成時に照合順序の競合エラーが出た

    SQL ServerでViewの作成時に照合順序の競合エラーが出た。Japanese_CS_ASとJapanese_CI_ASで照合順があわないとのこと。Select文を単体で実行するとエラーにはなっていない。

    equal to 操作の"Japanese_CS_AS"と"Japanese_CI_AS"間での照合順序の競合を解決できません。

    調べていくと、DB上のテーブルの照合順は、「Japanese_CI_AS」で統一されていた。Select文を見直していくと、Where句で照合順を指定しており、これがテーブルと異なっていたため、競合エラーが発生していた。VIEWのときは、テーブル側と照合順が合致している必要があり、これを見落としていたのが原因だった。WHERE句で指定していた照合順をDB上のテーブルで指定されているものに変更した。

    WHERE  項目名 = '値' COLLATE Japanese_CS_AS

    注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。

  • SQL Serverの名前付きインスタンスはUDP 1434を使用する

    SQL Serverへの接続に使用するポートは、通常、TCPの1433番ポート。デフォルトでインストールしたSQL Server(既定のインスタンス)しかなければ、これで接続できる。名前付きで、SQL Serverをインストールした場合は、SQL Server Browerサービスを使用することにより、1434番ポートで、UDPを使用する。

    SQL Serverでポート番号を調べると、1433と1434が出てくるのだが、これをTCPだけで設定してしまうと、SQL Server Browerサービスを介した名前解決でエラーになる。エラー時には、エラー番号の26なので、SQL Server Browerサービスの起動を確認するのだが、これが起動されている場合には、UDPの1434番ポートが通信可能になっているかを通信経路上(SQL Serverのサーバと、経路のネットワークと、クライアント)で確認する。

    Provider: SQL Network Interface, error: 26

    さらに注意事項として、名前付きインスタンスが動的ポートで構成されるようになっている場合(デフォルトだと動的ポート)、1433番ポートを使用して、SQL Serverが起動していない。名前付きインスタンスの1つしかインストールされていない場合には、起動ポートを1433に固定することで、他のポートは空けなくてもよい。

    参考: https://docs.microsoft.com/ja-jp/troubleshoot/sql/connect/resolving-connectivity-errors

  • SSMSでテーブルのデータからINSERT文を生成する

    SSMS(SQL Server Management Studio)のバージョンは、18.5で確認。

    1. SSMSを開き、SQL Serverに接続する。
    2. INSERT文を作成するDBを選ぶ。
    3. 右クリックから「タスク」「スクリプトの生成」を選ぶ。
    4. ウィザードが立ち上がる。
    5. 「次へ」をクリックする
    6. INSERTを作成したいテーブルを選び、「次へ」をクリックする。
    7. スクリプト作成オプションの設定画面になるので、「詳細設定」をクリックする。(ここがポイント)
    8. 「スクリプトを作成するデータの種類」でプルダウンから「データのみ」を選択する(ここがポイント)
    9. 「OK」をクリックする
    10. 保存方法を選択して、「次へ」
    11. 内容を確認して、「次へ」
    12. 結果が成功になっていれば、「完了」をクリックして終わり。
    13. 保存先を確認する。

    この手順でわかりにくいのが、「詳細設定」から「スクリプトを作成するデータの種類」を探して「データのみ」を選択するところ。ここを変更しないと、スキーマの情報しかスクリプトとして作成してくれない。

  • Veeam BackupがRPCの呼び出しに失敗してエラーになる

    Veeam Backupで仮想マシンのバックアップかつSQL Serverのバックアップを行ったところ、下記のエラーでバックアップの取得が失敗した。

    Processing Server01 Error: Failed to check whether snapshot is in progress (network mode). RPC function call failed. 
    Function name: [IsSnapshotInProgress]. 
    Target machine: [Server01.ad.xenos.jp]. 
    RPC error:RPC サーバーを利用できません。  
    Code: 1722  01:41
    

    原因は、RPC(リモートプロシージャコール)へのアクセスがWindowsのファイアウォールで禁止されていたから。

    対応として、「セキュリティが強化されたWindows Defenderファイアウォール」を開き、「スケジュールされたリモートタスク管理(RPC)」と「スケジュールリモートタスク管理(RPC-ESMAP」の許可ルールを有効にする。

    参考: https://www.veeam.com/kb1174

  • Veeam BackupでCode 53エラーが発生する

    Veeamで仮想マシンのバックアップで、SQL Serverのバックアップの取得設定を行ったところ、Code 53のエラーが発生して、バックアップに失敗する。

    Processing Server01 Error: Failed to connect to guest agent. 
    Errors: 'Cannot connect to the host's administrative share. Host:  [Server01.ad.xenos.jp]. 
    Account: [administrator@ad.xenos.jp]. Win32 error:ネットワーク パスが見つかりません。  Code: 53 Cannot connect to the host's administrative share. Host:  [192.168.0.11]. 
    Account: [administrator@ad.xenos.jp]. Win32 error:ネットワーク パスが見つかりません。  Code: 53 '    01:22
    

    原因は、バックアップ対象のファイアウォールの設定。Veeam Backup は、管理共有を使用して、VM上のSQL Serverのバックアップを取得する。Windows ファイアウォールの設定で、ファイル共有を許可する設定にしていないのが原因。

    対応として、「セキュリティが強化されたWindows Defenderファイアウォール」を開き、「ファイルとプリンターの共有(SMB受信)」の許可のルールを有効にする。

    なお、「ファイルとプリンターの共有(SMB受信)」が許可されていない場合、「RPC」の接続も許可されていないと思われるので、「RPC」も許可しないと別のエラーが発生する。

    参考: https://www.veeam.com/kb1230

  • SQL ServerでDBをオフラインにしたら、ユーザがSQL Serverにログインできなくなった

    SQL Serverで使わないDBをオフラインにしたところ、そのDBが「既定のデータベース」だったユーザはログインできなくなった。SQL Server Managment Studioでログイン時に、エラーがでて接続できなくなった。

    ログインできなくなったユーザの既定のデータベースをオンラインの別のDBに変更することで、ログイン問題は解決した。

    SQL Serverで使っていないDBをオフラインにするときは、そのDBが「既定のデータベース」になっているユーザがいないかどうかを注意する必要がある。