問題タブ [dbcc]

私は DBA と協力して、いくつかのステップを順番に実行するよう依頼しています。

最後に Sybase ASE で DBCC Checkstorage を実行したときに、どのコマンドを実行すればよいですか?

次の情報を含むデータベース[MyDB]があります
。SQLServer2008MDF
サイズ：30 GB
LDFサイズ：67 GB

ログファイルをできるだけ縮小したかったので、これを行う方法を見つけるために探求を始めました。警告：私はDBAではなく（またはDBAに近づいていません）、この探求を通して感じて進歩してきました。

まず、SSMS、DBプロパティ、ファイルに移動し、初期サイズ（MB）の値を10に編集しました。これにより、ログファイルが62 GBに減少しました（入力した10 MBとは異なります）。そこで、SQLプロファイラーをアタッチして、DBCCSHRINKFILEが呼び出されていることを確認しました。次に、そのコマンドをクエリエディタに入力しました。結果は次のとおりです。

そして、出力は次のとおりです。

それから私はそれについていくつかの調査をし、これを見つけました：

http://support.microsoft.com/kb/907511

これは、仮想ログファイルが解放され、シュリンクファイルがその仕事を実行できるように、シュリンクファイルの前にログファイルをバックアップする必要があることを示しています-それが何を意味するのかわかりません...私はここで言い換えています:)

したがって、ログファイルをバックアップしてからDBCC SHRINKFILEを実行しようと考えました（前のDBCC SHRINKFILEコマンドの出力で識別されたMinimumSizeであったため、新しいログファイルサイズを12800に変更しました）

結果は最初の周回と同じでした。ログファイルは62GBまでしか取得できません。

何が間違っているのか、次に何を試すべきかわかりません。

現在実行中のストアド プロシージャがあり、特定のクエリでハング/ロックしているようです。どのクエリを確認できますか? できればprocを変更せずに。

使用する

私にくれます

言語イベント 0 EXEC mySP;

スクリプトで ID 列を持つテーブル変数を作成し、この列を再シードしたいと考えています。以下のスクリプトを使用できますか?

起動時に、再起動中のインスタンスのすべてのデータベースに対して実行されている CHECKDB があることに気付きました。最初はそれが標準的な手順であると想定し、いくつかの調査を行いました。データベースを適切に閉じることができずにサーバーがダウンした場合に、これが発生することを示すいくつかの投稿を見つけました。

それは理にかなっていますが、なぜこれらの CHECKDB がスピンするのに数分しかかからないのでしょうか? PHYICALONLY でさえ、完了するまでに 1 時間以上かかるはずです。

DBCC CHECKCONSTRAINTSデータベースで TSQL を実行し、発生したメッセージを として返すSmo メソッドはありますIEnumerable<String>か?

制約チェックをオフにしたバルクロードの後、制約に違反しているため、外部キー列のいくつかのレコードを削除する必要があります。DBCCはそれらをうまく示していますが、この[colARef] ='XXX' DBCC表記の違反値を取得する簡単な方法はありますか？つまり、解析せずに、主キーを検索して削除できる値を取得します。
ありがとう

DBCC SHOW_STATISTICS コマンドから情報を抽出したいと考えています。だから私はサブクエリでこれをやろうとしてきましたが、今までは不可能のようです。Google経由で、一時テーブルに関するいくつかの提案が見つかりましたが、これには最初に一時テーブルを定義する必要があるようです.

解決策はありますか、またはこれが不可能であることを確認できますか?

dbcc shrinkfile(m,n) connamd の意味を知りたいと思っただけです。コマンドを実行すると言う

その 1,2000 は何を示していますか?

dbcc は通常の SQL 縮小とどう違うのですか (DB を右クリックしてタスク > 縮小 > ファイルを選択した場合)。

新しいサーバーに移動するSQLServer2008データベースが本番環境にあります。現在のデータベースには、最大400GBの.MDFファイルが1つあります。新しいサーバーはSQLServer2012を実行し、ミラーリングされたIntel910SSDを実行します。これらのドライブは、4x200GBのパーティションを提供します。

これを機能させるには、を使用してシングル.MDFを4つの小さなものに分割する必要がありDBCC SHIRNKFILE with EMPTYFILEます。私たちはこれをテストで行いましたが、それでも約3.5時間かかりますが、これは長すぎます。既存のデータベースはOLTPであり、365/24/7であり、このプロセス中にブロッキングが発生することがわかっているため、最初に本番環境でそれを行うことはできません。

私の質問ですが、データベースを一時的な場所にある新しいサーバーにバックアップして復元し、新しいファイルを作成し、新しい場所にEMPTY一時的なものを作成して.MDFから、トランザクションログを適用する方法はありますか？そうすれば、現在の古い本番環境が稼働している間にデータを移動してから、短時間のシャットダウンを実行し、ログを適用して、新しいDBを起動できますか？

または、ダウンタイムを最小限に抑えて、異なるドライブ上の1つのファイルでサーバーAと4つのファイルでサーバーBから取得する他のオプションはありますか？