2

データベース全体をバックアップするため、SQL Server の組み込みのバックアップ機能を使用できない理由がありました。これらの顧客は、データベースを分割し、データの所有者のサブセットにバックアップして、適切な関係者が独自のルールに従って独自のデータをバックアップできるようにする必要があります。私の質問は 2 つあります。

  1. どうすればこのようなことをすることができますか?
  2. バックアップをこのように分割するよう求められたことはありませんか? そうでない場合、業界標準に反しているように見える何かをするように頼まれたことがありますか? 社内の人々は、データの必要なサブセットだけをバックアップする「独自の」バックアップ プロセスを作成する必要があると提案しています。もちろん、これは、私たち/私が単に「独自の」復元プロセスを実行する必要があることを意味します。これが車輪の再発明の定義であり、そもそも SQL Server を選択した理由の一部であると私が主張するとき、彼らは私が技術的なスノッブであり、怠け者であると考えているように感じます。

彼らの意見は、Access ベースの別の製品での経験に基づいており、各論理ユニットを単純にコピーできる別のデータベースに格納していたのではないかと思います。

更新: SMO を使用して「完全な」データベースをバックアップし、バックアップを復元し、サブセットの一部ではないバックアップからレコードを削除することで、最終的にこれを実装することに成功しました。これにより、トランザクション ログが 5 分間で 5 GB を超える結果になったことに非常に失望しています。空のデータベースを作成して挿入する方が簡単に思えますが、データベースの更新に合わせて更新する必要がある静的スクリプトを使用せずにスキーマを複製するにはどうすればよいでしょうか?

4

5 に答える 5

1

上級顧客向けに DB を開き、顧客に自分のデータだけを操作していじらせる簡単な方法です。それを使用して、データソースに直接アクセスできる独自のレポートを作成し、それを使って好きなことを行うことができます。

「バックアップ」ではなく、データの「エクスポート」と「インポート」と呼びます。しかし、それは言葉遊びです。一部のシステムでは、この種のエクスポートを頻繁に行っています。

「方法」については、より多くの情報を入手する必要があります。別のサーバー、同じサーバーで別のデータベース、または他のサーバーにエクスポートする必要がありますか?

これは、夜間に実行されるジョブまたはデータをプッシュするサービスによって実行できます。これには他のツールも存在します。夜間またはトリガーされた DTE パッケージを使用している可能性があります。または、要求されたときにデータをフェッチするプログラムを作成します。

編集:コメントに答えてください:
ほとんどの場合、既存のsubsetdbを削除してから空のdbを復元し、フィルタリングされたデータで埋めます。別の方法は、完全にバックアップし、新しいデータベースとして復元し、サブセットの一部ではない行を削除することです。

私は、subsetdb は統計データを含む「読み取り専用」のデータベースであると推測しているため、変更の上書きなどを心配する必要はありません。

于 2009-01-20T00:52:52.320 に答える
1

特に、ホストされたソリューションを提供し、複数の顧客間で単一のデータベースを共有している場合、または同様のことを行っている場合、企業がこれを行う理由は完全に理解できます。customerId フィールドでレコードをフィルタリングしてファイルにドロップするだけで機能するようで、それで終わりです...しかし、彼らはこれに火をつけています。

問題のデータベースを見ずに、なぜこれが悪い考えなのかを指摘するのは困難です。しかし、いくつかすぐに思い浮かびます。

  1. トランザクション ログ バックアップの損失。

  2. 自動インクリメント ID は、「欠落している」レコードを手動で挿入するのに親切ではありません。挿入中に IDENT 機能や制約をオフにすると、参照整合性の問題が発生するだけです。

  3. 共有データはどうですか?複数の顧客間で使用されているテーブルはありますか? そのデータが時間の経過とともに変化するとどうなりますか? そのデータだけの最新のバックアップをどこから取得しますか? また、同じデータベースに住んでいる他の顧客にどのような影響がありますか?

  4. 外部キー...すべてのテーブルを分析し、外部キーのないテーブルが最初に挿入されるようにする必要があります。不可能ではありませんが、エラーの余地がかなりあります。

  5. スキーマが変更されるとどうなりますか? このすべてのデータを個別の挿入としてバックアップしている場合、スキーマのバックアップを一致させないと、そのままでは機能しなくなります。

考慮すべきことはすべてあります。個人的には、私が彼らだったら、データベース全体の 1 つの SQL Server バックアップから始めて (できれば、1 つの大きなデータベースをすべて共有するのではなく、顧客を別々のデータベースに分けて)、差分を毎日 (または最適なスケジュールで) 作成します。彼らのニーズに合っています)。次に、追加サービスとして、データをエクスポートおよびインポートする何らかの方法を提供できます。それは、XML や CSV などを介して行われます。お客様は、エクスポートを通じてデータのバックアップを実行できます。必要に応じて、いつでも再インポートして、重複チェックなどを行うことができます。

このアプローチにより、Microsoft の基準を満たすバックアップを復活させる方法があることを常に保証できます。データはおもちゃではなく、SQL Server もただの獣ではありません。SQL Server のバックアップ プロセスに関して言えば、データベースからデータを取り出してどこかに放り込むだけではありません。データを適切に保護できないだけで、会社全体が倒産する可能性があります。最悪の部分は、ほとんどの企業が、カスタム バックアップ プロセスが復元時に機能しないことに最後の最後まで気付かないことです...痛い

最後になりましたが、仕事に適したツールがあるかもしれません。Red Gate は、SQL Server Compare、Data Compare、独自のカスタム バックアップ アプリケーションなど、優れた SQL Server ツールを多数提供しています。とにかく、私はそれらを最後の手段として使用します...

http://www.red-gate.com/

于 2009-01-20T01:05:03.887 に答える
1

簡単に言えば、これを処理するネイティブな方法はありません。

より長い答えは、スキーマだけで新しいデータベースを作成し、メインデータベースから顧客データをロードした場合、小さなデータベースを単一のバックアップファイルにバックアップして顧客に渡すことができるということです。

SSIS は、そのネイティブ タスクを使用してすべてのテーブル スキーマを取得し、それらを空にしてから、顧客固有のテーブルの変換を定義し、ルックアップ テーブルをループしてそれらすべてのテーブルのデータをコピーできるため、おそらく最善の策です。

于 2009-01-20T02:14:35.463 に答える
0

本当にこのようなことをしなければならない場合、おそらく最も安全な方法は、データのサブセットの何らかの種類 (レプリケーション、サービス ブローカーなど) を独自のデータベースに転送することです (バックアップ可能なサブセットごとに 1 db)。その後、それらのデータベースをバックアップできます。

あなたはサブセットのみを扱っているので、データの損失がないことを保証するので、これにはサービスブローカーを使用します。

于 2009-01-20T11:06:58.133 に答える
0

複数のデータベースを作成するオプションはありますか? 1 つの「中央」データベースに、他のデータベースのテーブルを効果的に結合するビューが含まれるソリューションを導き出すことができる場合があります。一部の Web フィルタリング アプリがこれを行うことは知っていますが、もちろん、この方法で更新を行うわけではありません。しかし、それは実行可能かもしれません。その場合、ネイティブの手段を使用してすべてのデータベースをバックアップできます。

于 2009-01-20T02:19:36.047 に答える