問題タブ [dbcc]

プロジェクトの顧客から入手した 31 GB のデータベースがあります。私は 80GB の Win7 VM でデータベースをコーディングして保持しています。db ファイルを取得し、そこからデータベースをインポートしたところ、240,000 枚の画像を含む 1 つのテーブルがほとんどのスペースを占めていることがわかりました。これらの行のほとんどを削除し、現在 29,000MB を使用できます。ドライブが最後の数 GB に達しているため、多くの機能を実行できません。また、変更するレコードがまだたくさんあります (いくつかのテーブルのデータ型を変更していますが、active_transaction エラーが発生し続けます)。DBCC_SHRINKDATABASE(0)またはTasks > Shrink > Databaseまたはファイルを介して縮小していません。最初に取得したときのデータベースのサイズに縮小するだけのようです。そのスペースを解放するにはどうすればよいですか？可能であれば、まだ残っているデータを小さなデータベースにエクスポートして、そこから復元できますか?

SQL Server 2012 と Management Studio を実行しています。

ありがとう、

トニー

このエラーに遭遇し、助けを求めていたエンド ユーザーがいます。フル バックアップを作成できません。以下のエラー メッセージが表示されます。エラーが発生した後も続行するために完全バックアップを実行しようとしましたが、それでも失敗します。はい、SQL サービスはディスクに完全にアクセスできます。同じサーバー上の他のデータベースの完全バックアップを取得できました。

メッセージ 3203、レベル 16、状態 1、行 1 "R:\MSSQL10\Database.mdf" の読み取りに失敗しました: 23 (データ エラー (巡回冗長検査)) メッセージ 3013、レベル 16、状態 1、行 1 バックアップ データベースは異常終了します。

checkdb を実行すると、repair_allow_data_loss を実行するように言われました。allow data loss を実行せずにこのエラーを修正する方法はありますか?

ここで質問するのはこれが初めてですが、過去にスタックオーバーフローを何度も使用して、コードで発生した問題の解決策を見つけました。

私はcsvファイルをアップロードしてデータベースを更新するphpサイトのデータベース転送ページに取り組んでおり、ユーザーが選択した更新の種類に応じて、このデータをキーで更新/挿入できます。このため、更新が行われた後に DBCC CHECKIDENT を実行して、テーブル内の最大のキーの後に新しいエントリが正しくインクリメントされるようにしたいと考えています。

これは私が実行しているphpコードです:

$t は、テーブル名の配列に格納されているテーブル名です。

このコードから次のエラーが発生します。

私を混乱させているのは、ペースト DBCC CHECKIDENT ('table', RESEED, 16) をサーバー管理スタジオにカットすると、それが機能し、次のようになることです。

誰かがこれを引き起こしている考えを持っている場合、またはこの問題に対処するために私が見逃した投稿がある場合は、どんな助けも大歓迎です.

以下はクエリクラスです。私はそれをしませんでした：

DBCC CheckDB "myDB" プロセスが正常に完了した後、Temp db データ ファイルが OS への領域をクリアまたは割り当て解除していません。SP_WhoIsActive スクリプトを使用して診断し、DBCC CheckDB プロセスが一時データベースの増加を引き起こしていることを発見しましたが、SP_WhoIsActive を使用して見たように、DBCC CheckDB が一時データベースを使用しているのは約 16 GB の 1 つのデータベースでのみ発生しています。

注: SQL Server を再起動すると、tempdb は OS に割り当てられた領域を解放しますが、DBCC チェック DB ジョブの実行後に 45 GB に増加し、使用済み領域の割り当てを解除しません。

コマンド「DBCC CHECKDB」に関するMSDN の記事では、構文セクションでデータベースの修復を実行する 3 つの方法について説明しています。

しかし、疑わしいデータベースを修復する方法を探していたときに、次のステートメントを見つけました。3 つのモードのどれがそれであるかを理解できません。

DBCC CHECKDB (データベース名、修復)

ステートメントを実行しましたが、正常に動作します。「_allow_data_loss」、「_fast」、または「_rebuild」で単語を終了せずに「repair」パラメーターだけを参照することはできないため、混乱しています。

前もって感謝します、

SQLサーバーでテーブルをデフラグしたいので、このコードを使用して断片化されたインデックスを知りました：

使用した結果が得られた後

最適化されたインデックスに戻り、最初のコードを再利用して結果を表示します。それの何が問題なのですか?どうすればインデックスを修正できますか?

出力

ここでd8とは何ですか?

それぞれ5.5kk行の約300のテーブルがあります。行の 1 つは nvarchar(128) をデータ型として使用しています (SQL Server 2012)。
これを int に変更し、すべての nvarchar を含むディクショナリ テーブルに FK を追加することにしました。

すべてを実行した後、nvarchar 列を削除しましたが、テーブルのサイズは同じままでした。DBCC CLEANTABLE を使用し、インデックスを再構築して空き領域を再利用しましたが、テーブルのサイズはまだ変化していません。

これまでのところ、私が見つけた唯一の方法は、すべてのデータを新しいテーブルにコピーすることです。

質問: ここで何が欠けていますか? スペースがまだ使用済みとしてマークされていて、縮小または CREANTABLE コマンドで解放できないのはなぜですか?

ありがとうございました！

回答:答えはかなり単純なようで、私の知識不足で見つけることができませんでした。ここでの主な問題は、ヒープの断片化でした。このクエリは私のために働いた：

それが最善の方法かどうかはわかりませんが、少なくとも機能する方法です。

Edited1 :申し訳ありませんが、言及するのを忘れていたと思います-テキストフィールドにクラスター化されたインデックスがあったため、実際にフィールドを削除できるようにするには、インデックスを削除する必要がありました。今、私はインデックスを持っていません。

編集済み2 :

古いテーブル:

新しいテーブル:

スクリプトをコピー:

Google で調べたところ、フィル ファクターが 0 の場合、インデックス ページの 100% のスペースが使用されることがわかりました。それ以外の場合は、フィル ファクターを指定する必要があります。

専門家への私の質問は次のとおりです。

1. インデックスの効率を最大化するには、空白のままにしておく必要がありますか?

2. 一部のデータベースで、一部のインデックスについて記載されているフィル ファクターが 80、85、90、100 であることがわかりました。では、フィル ファクターを 80 または 90 と指定する必要があるのはいつでしょうか。

   fill_factor <> 0 である sys.indexes から fill_factor,* を選択します。