2

同一のスキーマを持つべきデータベースが 18 個ありますが、そうではありません。特定のシナリオでは、テーブルが 1 つに追加されましたが、残りには追加されませんでした。または、一部のデータベースでは特定のストアド プロシージャが必要でしたが、他のデータベースでは必要ありませんでした。または、DBA がスクリプトを実行してすべてのデータベースにビューを追加するのを忘れていました。

データベース スキーマの同期を維持する最善の方法は何ですか?

4

8 に答える 8

4

Red Gate のSQL Compareは、このための優れたツールです。

于 2008-09-18T15:52:11.870 に答える
4

レガシーの修正/クリーンアップには、データベースを同期するためのスクリプトを生成できるSQLCompareなどのツールがあります。

SQL Server を実行している .NET ショップには、Visual Studio Database Editionもあります。これは、ソース管理にチェックインできるスキーマ変更の変更スクリプトを作成し、CI/ビルド プロセスを使用して自動的にビルドできます。

于 2008-09-18T15:53:59.760 に答える
3

SQLCompareは、データベース間の違いを見つけて同期するために使用した最高のツールです。

データベースの同期を維持するには、いくつかのものが必要です。

1) 誰が本番環境に変更を加えることができるかについてのポリシーが必要です。通常、これは DBA (大規模な組織の場合は DBA チーム) と 1 つまたは 2 つの backap のみにする必要があります。バックアップは、DBA が不在のとき、または緊急時にのみ変更する必要があります。バックアップは定期的に展開するべきではありません。このポリシーに従ってデータベース権限を設定します。

2) 導入リクエストを管理するためのプロセスとツール。理想的には、開発環境、テスト環境、および実稼働環境を用意します。開発者は、開発環境で初期開発を行い、必要に応じて変更をテストおよび本番環境にプッシュする必要があります。変更をプッシュするタイミングを DBA に知らせる何らかの方法が必要になります。次のキューブに大声で叫ぶプロセスはお勧めしません。大規模な組織には変更管理委員会があり、変更は月に 1 回しか行われない場合があります。小規模な企業では、開発者がテストを要求するだけで、テストが完了した後、本番環境への展開の要求が渡される場合があります。私が働いていた小さな会社では、これらの要求にProblem Trackerを使用していました。

状況と予算内で機能するものは何でも使用し、プロセスと、そのプロセスで機能するツールを用意してください。

3) あなたは、オブジェクトがほんの一握りのデータベースに行くだけでよい場合があるとおっしゃいました。おそらく 1 台のサーバー上に 18 個のデータベースしかないため、各データベースをオブジェクトに正確に一致させることをお勧めします。usp_DoSomething が必要なのは 5 つの DB だけですか? だから何？すべてのデータベースに入れます。これにより、管理がはるかに簡単になります。約 250 ～ 300 DB の 6 サーバー システムでこの方法を実行しました。例外はありましたが、それらはグループ化されました。サーバー C のデータベースは、この追加のオブジェクト セットを取得しました。サーバー L のデータベースは、この別のセットを取得しました。

4) DBA が変更スクリプトをすべての DB にデプロイするのを忘れることがあるとおっしゃいました。これは、変更をデプロイするためのツールが必要であることを示しています。S/彼はおそらく SQL スクリプトを取得し、それを Query Analyzer または Manegement Studio (または使用するもの) で開き、手動で各データベースに移動して SQL を実行します。これは、長期的 (または短期的) な解決策ではありません。 Red Gate (上記の SQLCompare の作成者) には多くの優れたツールがあります。マルチスクリプト展開目的で機能する可能性があるようです。私は、O-SQl を使用して SQL Server 2000 で独自のツールを作成した DBA と協力しました。SQL ファイルを取得し、サーバー上の各データベースで実行します。彼はそれを各サーバーで実行する必要がありましたが、各 DB で実行するよりも優れていました。また、同じことを行う VB.net ツールの作成も手伝いましたが、サーバーのリストも通過するため、一度だけ実行する必要がありました。

5) ソース管理。私の現在のチームはソース管理を使用しておらず、これが引き起こす問題の数をお伝えする時間がありません。なんらかのソース管理システムを持っていない場合は、入手してください。

于 2008-09-18T17:18:59.507 に答える
1

上記の回答についてコメントするほどの評判はありませんが、SQL Compare のプロ バージョンにはスクリプト可能な API があります。これらすべてのデータベースに複製する必要がある場合、これを使用して自動化されたジョブを作成し、変更スクリプトを生成するか、データベースがすべて同期していることを検証できます。また、標準バージョンよりもそれほど高価ではありません。

于 2008-09-18T15:56:00.987 に答える
1

データベース比較ツールを使用する以外に、18 個のデータベースがある場合は DBA が必要です。そのため、CREATE および ALTER へのアクセスを DBA のみに制限することで、DBA のみがデータベース レベルでテーブルを変更できるというポリシーを適用します。テスト データベースとライブ データベースの両方で。もちろん、開発データベースにはこれがないはずです! スキーマを作成または変更している開発者に、DBA を経由させます。

于 2008-09-18T15:59:53.223 に答える
1

リリースごとにソース管理された DDL/SQL スクリプトを 1 つ作成し、それをデータベースの更新にのみ使用します。差分ツールは便利ですが、主に、間違いを犯していないことを確認し、ポリシーが失敗したときに問題を解決するために使用されます。DDL、SQL、およびストアド プロシージャ スクリプトを 1 つのスクリプトに結合して、スクリプトの 1 つを実行するのを簡単に「忘れる」ことがないようにします。

于 2008-09-18T17:47:22.357 に答える
0

この投稿は古いと思いますが、TurnKey は正しいです。チーム環境で作業する開発者の場合、大規模なアプリケーションのデータベース スキーマを維持する最善の方法は、使用するソース セーフでマスター スキーマを更新することです。独自の Scripting クラスを作成するだけで、データベースは常に完璧になります。

于 2013-10-03T20:00:25.840 に答える
0

データベース スキーマを比較および同期できる DB Schema Difftective というツールがあります。もう 1 つのツールである DB MultiRun を使用すると、生成された (同期) スクリプトを複数の db サーバー (プロジェクト ベース) に簡単に展開できます。

于 2009-05-19T12:00:09.450 に答える