SQL VDIを介したデータベースバックアップ

Microsoft SQL Server用に独自のデータベースバックアップを作成する方法と、その結果についてお話したいと思います。

問題

会社ではMicrosoft SQL Serverを使用していますが、そのためにデータベースのバックアップを行う必要があると予想されますが、これは成功しています。 これは次のように行われます。

• 最初のスクリプトは、必要なデータベースのバックアップを作成します
• 2番目のスクリプトは、バックアップのあるフォルダーを調べ、7zipでアーカイブします
• 3番目のスクリプトは、これらのバックアップを外部ストレージに保存します

私の意見ではすべてが論理的であるように思えますが、これにはある奇妙な点があります。 しばらくの間、サーバー上にアクティブにスペースを占有しているファイルがあるため、これらのファイルは不要として削除されます。 これをすべて最適化したかった。 さらに、当社には製品があり、そのタスクの1つはデータベースを同期することであり、タスクを最適化する同様のコードも非常に便利です。

ソリューションオプション

SQL圧縮バックアップ

良いアイデアですが、SQLのすべてのバージョンがサポートしているわけではなく、このバックアップのサイズはまだ最小ではありません。 また、ほとんどの場合、バックアップが役に立たないという事実を考慮して、より多くの圧縮が必要です。 しかし、利便性の面で素晴らしいオプション。

Azureでのバックアップ

2012年以降、SQL ServerはAzureでのバックアップをサポートしています。 独自のサービスをURLとして指定し、その中ですべてを実行するというアイデアがありました。 しかし、非常に複雑で汚い技術が登場しました。 また、SQLのバージョンはかなり新しいはずです。

パイプ内のバックアップ

素晴らしいアイデアですが、2005年以降、SQLはサポートされなくなりました。

VDI経由のバックアップ

パイプに代わるマイクロソフトの秘密技術。 なぜ秘密ですか？ そして、そのドキュメントを見つけてください。 これは別のクエストです。 MicrosoftのWebサイトにはドキュメントがありますが、わかりやすいようですが、明確なものはありません。 それはVDIについてのように見えますが、VSSについてのようです。 さまざまなサイトでの転載と豪華な使用例があります。

実際、最も理解しやすいドキュメントは、 このリンクの chmファイルにあります

このすべてのドキュメントの後、純粋にサービステクノロジのような感覚がありましたが、 他に何も見つかりませんでした。 さらに、2005年のバージョン（2000年以降でも、いくつかの制限はあります）以降、すべてのエディションですべてのSQLに取り組んでいます。

VDIを使用する

何もする必要はありません。彼らはドキュメントを取り、アーニャを取り、ドキュメントを配り、グーグルでこの技術を研究するために送りました。





アーニャはドキュメントを研究しています。



この技術を思いついたら、これをするでしょう：

• SQLに登録された仮想デバイス
• パラメータを使用してこのデバイスにバックアップコマンドを作成します
• 使用方法についてユーザーに指示を書きます
• ?????
• 利益！

それは論理的ですが、Microsoftは簡単な方法を探していません。 彼らは次のスキームを思いついた

• ワンタイムデバイスをSQLにランダムな名前で登録します（通常は全員がガイドを使用します）
• SQLからのデータを待機しています
• 同時に、別のスレッドによってこのデバイスへのバックアップを作成します（自分で名前を発明したため、私たちだけが呼び出すことができます）
• SQLピースからデータを取得する
• すべてを取得し、デバイスを閉じて、データベースのバックアップコマンドを終了します

もちろん、すべてが「素晴らしい」COMで書かれているので、人生は蜂蜜のようではなく、次の制限で味付けされています。

• SQLとアプリケーションは同じサーバー上にある必要があります（ありがとう、異なるSQLインスタンスがサポートされています）
• SQLユーザーはsysadminでなければなりません（適度）
• アプリケーションを実行しているユーザーは、管理者またはグローバルオブジェクトの作成の魔法の権限を持つユーザーである必要があります。

最後のポイントはより詳細です。ドキュメントには次のような傑作フレーズがあります。

CreateEx（およびCreate）呼び出しは、クライアントプロセスのプロセスハンドルのセキュリティDACLを変更します。 このため、プロセスハンドルの他の変更は、CreateExの呼び出しでシリアル化する必要があります。 CreateExは、CreateExへの他の呼び出しでシリアル化されますが、外部処理でシリアル化することはできません。 SQL Serverサービスを実行しているアカウントへのアクセスが許可されます。

フォームの典型的なフレーズ： 敗者のように感じる 。 つまり すべての言葉は理解できますが、意味はありません。 実際、上記で書いたように、 グローバルオブジェクトの作成権限が必要です。これは、デフォルトで管理者、ネットワークサービス、およびローカルサービスが使用できます。 つまり 原則として、すべてはサービスから開始できますが、管理者は開始できません（通常、バックアップを作成するユーザーは管理者ではありません）。 ただし、グループポリシーを介して、ハンドルによって権限を付与できます（指定したユーザーに権限を付与するユーティリティでコマンドを作成しました。つまり、管理者の下で発行されたら、作業を続行できます）。 残念ながら、彼らはUACに対処できませんでした。 管理者の下でプログラムを明示的に実行することを忘れた場合、いかなる方法でも権利を取得できません。 マニフェストで管理者権限が必要であることを明示的に示すことはできましたが、原則として、プログラムを管理者として使用することは機能しません。 そして、私はしたい。



私たちはそれを理解し、先へ進みました。 コードの一部を書いて何をすべきかを詳細にペイントすることはしません。これは誰にとっても面白くないからです。 :)通常、GetCommand、CompleteCommandの形式の定期的なサイクルがあり、その途中で結果が処理されます。 .NETでこのCOMを使用したときに出てきたニュアンスの一部を紹介します。

素晴らしいと恐ろしい

はい。すべてを.NETで作成することにしました。 実際、COMでのマーシャリングは非常に許容され（システムライブラリの半分は基本的にCOMのラッパーです）、問題はないと思われました。 しかし、それらはすべての段階で文字通り発生しました。

この部分は、すでにこれに遭遇した人にはおそらく明らかですが、遭遇していない人には興味深いかもしれません。

オブジェクトを宣言するとき、メソッドの名前は重要ではありません

重要なのは順序だけです（これはDllImport属性を持つWinAPIメソッドとは異なります）。 つまり 誤って2つのメソッドを場所（特にCreateやCreateExなどの類似のメソッド）で混同した場合、すべてが機能しているように見えるときに素晴らしいエラーをキャッチできますが、どういうわけかそうではありません。

これに注意してください。

.NETが実行をスローします

COMでは、メソッドは通常HRESULTを返します。 エラーコード。 まあ、またはすべてが順調であれば、0番目のコード。 .NETはこれを利用し、ゼロ以外のコードの場合、既にコードを見て処理できるCOMExceptionをスローします。 便利そうに思えますが、完全ではありません。 さらに、古い.NETを搭載したサーバーの1つで、顕著なバグが発見されました。 この実行が発生したとき（たとえば、ドキュメントによると通常は通常の状態です）、閉じたデバイスに切り替えると、ExecutionEngineExceptionが致命的なアプリケーションクラッシュでクラッシュしました。 Googleは更新プログラムをソリューションとしてインストールすることを提案しましたが、一般的に、これはユーティリティのソリューションではないため、次のように問題を回避しました：エラーが発生した場合にアクションをスローせず、単にエラーコードを返すPreserveSig属性を各COMメソッドに追加しました。 この場合、ひどい問題は発生しませんでした。 さて、コードはより論理的になりました。

STAThreadおよびMTAThread

.NET開発者にとって、これはスタジオがMainメソッドに追加する何らかの魔法の属性です。 誰かがそれが何であるかを理解しようとすると、そのシンプルさで次のエレガントなテキストを受け取ります。

STAThreadAttributeは、アプリケーションのCOMスレッドモデルがシングルスレッドアパートメントであることを示します。 この属性は、Windowsフォームを使用するアプリケーションのエントリポイントに存在する必要があります。 省略すると、Windowsコンポーネントが正しく機能しない場合があります。 属性が存在しない場合、アプリケーションはマルチスレッドアパートメントモデルを使用しますが、これはWindowsフォームではサポートされていません。

翻訳の意味：男、それは必要です。



もちろん、これはもちろん必要です。アプリケーションをzipでアーカイブすると、すべてがうまくいきました。7zを使用しようとすると、すべてがハングしてしまいます。 問題は何ですか？これらの属性は本当に何を意味しますか？



つまり、意味は次のとおりです。 COMは、すぐに使用できるマルチスレッドです。 つまり さまざまなオブジェクトがさまざまなストリームでデータを受信および返します。 しかし、krivorukyコード（またはWindowsフォーム）は、このような複雑な概念をマスターできないため、すべてのCOM呼び出しを内部キューにラップし、単一のスレッドで実行します。 マルチスレッドの問題はありません！ しかし、我々は壮大なデッドロックで立ち往生しています。 これがデッドロックであり、デッドロックが.NETの本質のどこかにあることを理解するのにどれくらいの費用がかかりましたか？



しかし、幸運なことに、コンソールアプリケーションがあり、MTAThread属性をハングさせて落ち着きました。 それがあなたに合わない場合...そして苦しみます。 回避策があります。

オブジェクトの作成は奇妙なことがあります

.NETは便利なラッパーを作成するため、オブジェクトのインスタンス化はシンプルで明白に見えます。

var obj = new ClientVirtualDeviceSet();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、32ビットWindowsですべてを実行しようとするまで、すべてが機能しました。 そして、オブジェクトの作成時に出ました。 データ型とマーシャリングの問題（適切なサイズではない）を想定するのは論理的でしたが、すべてが正常でした。 彼らは問題が何であるかを正確に見つけず、 CoCreateInstanceを介して古き良き時代にオブジェクトを作成しました。

 object comObject; var errorCode = CoCreateInstance( CLSID_MSSQL_ClientVirtualDeviceSet, IntPtr.Zero, CLSCTX_INPROC_SERVER, CLSID_MSSQL_ClientVirtualDeviceSet, out comObject);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その他

私はすべてのささいなことをマーシャリング、構造の正しいレイアウトで説明しません。原則として、それらは一度思い起こされて、もう触れられません。 ポインタを処理するのが難しい場合は、IntPtrを指定し、ペンで目的のタイプに変換してください。 .NETに適切な属性を選択するよりも簡単です

約7z

SevenZipSharpについてより正確に それは完全なラッパー（非常に良い）で、それから彼についてもです。



混乱を招く可能性のある最初のことは、ライブラリがファイル（ストリームではなく）を操作するために研ぎ澄まされていることです。 つまり .NETでは、コンプレッサーは通常、書き込み可能なストリームのラッパーであり、ユーザーはそれに書き込み、圧縮されたデータを圧縮して内部ストリームに転送します。 これに対して、SevenZipSharpでは、ストリームからデータを読み取り、内部ストリームに書き込みます。 一般的にSQLからも読んだという事実を考慮に入れると、アンナは非同期ストリーム、ロック、イベントの処理の楽しい時間をたくさん与えました...一般的に、アマチュアのために:)



再びファイルに関連する2つ目は、ライブラリが実際にさまざまな方向でストリームに沿って実行することを好むということです。これは一般的には良いことですが、ストリームが許可しない場合（stdoutなど）、問題が始まります。 原則として、gzip、xz、gzip、7zについてこれを回避することができました（その後、Anyaは私を嫌い始めました）。しかし、zipには困難がありました。 フロー構造ではこれが許可されていません。 stdinからの読み取りではさらに悪いことに、図書館は原則としてこれを行うことができません。 これまでのところ、この機会をあきらめなければならず、stdinからの非圧縮バックアップのみを読み取る機能のみを残していました。

まとめ

このすべての魅力的な探求の後、元の名前がPackDbであるユーティリティを取得しました。このユーティリティは、データベースをアーカイブに直接バックアップし、そこから復元し、ボーナスとして、一時ファイルを作成せずにデータベースをコピーします。 なぜこれが必要なのですか？ テストデータベースの場合、参照データベースを新しいデータベースにコピーし、メインデータベースに触れずにこのデータベースでテストする必要がある場合。 権利の発行、バックアップの正当性の検証、アーカイブを使用しない可能性など、必要がなければbakファイルを取得するだけです。







もしあなたがこの探求を行ったとしても、もしあなたが異常なバックアップを作りたいなら、あなたは自分で決める。 しかし、私の意見では、これは非常にありがたい仕事です。 ニュアンスが多すぎて、すべてが美しくなりません。