0

本番データベースからバックアップを復元してから、SQLスクリプト（ALTER TABLE、INSERTなど）を自動的に再適用して、そのdbスキーマを開発中のものに戻す必要があります。

一握りの異なる開発者からのたくさんのスクリプトがあります。それらはすべて同じディレクトリにあるわけではありません。

私の現在の計画は、疑似システムデータベースのテーブルに完全なファイルシステムパスを持つスクリプトを一覧表示することです。次に、このデータベースにストアドプロシージャを作成します。このストアドプロシージャは、最初にRESTORE DATABASEを実行し、次にスクリプトのリストにカーソルを合わせて、スクリプトごとにSQLCMDのコマンド文字列を作成し、xp_cmdshellを使用してスクリプトごとにそのSQLCMD文字列を実行します。

cursor-> sqlstring->xp_cmdshell->sqlcmdのシーケンスは私には不器用に感じます。また、xp_cmdshellをオンにする必要があります。

このようなことをしたのは私だけではありません。サーバー上のファイルシステムに散在している一連のスクリプトを実行するためのよりクリーンな方法はありますか？特に、xp_cmdshellを必要としない方法は？

4

2 に答える 2

1

まず最初に、Aナンバーワンで、すべてのデータベーススクリプトを1つの中央の場所に収集します。ソース管理またはバージョン管理のいくつかの形式が最適です。これにより、誰がいつ何を変更したか（他に何もない場合はdiffツールを使用して）理由を確認できます。データベースの作成に使用したコードをネットワークのあちこちに残しておくと、災害のレシピになる可能性があります。

次に、データベースに対してスクリプトを実行する必要があります。つまり、それらを実行するには誰かまたは何かが必要です。つまり、コードを実行する必要があります。SQL Server内からこのコードの実行を実行している場合、ほとんどの場合、xp_cmdshellを使用することになります。代替案？データベースに対してスクリプトを実行できる他のものを使用してください。

この種の問題に対する私の現在の解決策は、スクリプトをテキスト（.sql）ファイルに保存し、ファイルをソース管理に保存し、実行される順序を注意深く追跡することです（たとえば、CREATE TABLES get run後続の列を追加するALTERTABLEの前）。次に、バッチファイルを作成します（ええ、私はしばらく前からありますが、これはほとんどすべての言語で実行できます）。SQLCMD（SQL 2005を使用しており、以前はosqlを使用していました）を呼び出して、これらのスクリプトを実行します。必要なデータベースに対して。

「自分でロール」したくない場合は、このプロセスの管理に役立つより正式なツールが存在する可能性があります。

于 2010-04-14T14:31:56.290 に答える
0

Phillip Kelleyによる集中化とソース管理に関する提案に加えて、.NETに精通している場合は、SQL Server SMO（SQL Server管理オブジェクト）を使用する小さなWinFormsまたはWebFormsアプリを作成することを検討してください。これを使用すると、スクリプトをManagement Studioにドロップした場合と同じように、スクリプト全体をデータベースに渡すことができます。これにより、xp_cmdshellとsqlcmdが不要になります。もう1つのオプションは、ファイルを読み取り、ループでT-SQLの実行タスクを使用するDTS/SSISパッケージを作成することです。

于 2010-04-14T15:01:14.793 に答える