タグ付けされた質問 「dbcc」

6
ログファイルを圧縮してもサイズは小さくなりません
350 MBのデータファイル（.mdf）と4.9 GBのログファイル（.ldf）を持つデータベースがあります。復旧モデルはに設定されFULLます。 ログファイルを圧縮しようとしても、圧縮されません。 データベースの縮小は良くないことを知っています。しかし、私はまだログファイルを縮小するためにそれをやろうとしています。 走ったとき DBCC SQLPerf(logspace) ログサイズは4932 MBで、使用されるログ領域は98.76％であることがわかりました。 それから私はこのコマンドを試しました USE <databasename>; DBCC loginfo; 現在、ほとんどすべてのVLFは「ステータス2」であり、すべてが使用中であることを意味します。 ログのバックアップを取り、ログファイルを圧縮しようとしました。縮小してもサイズは小さくなりませんでした。 復旧モデルをに変更し、SIMPLE再度縮小しようとしましたが、これも役に立ちませんでした。 未処理のトランザクションを確認しました DBCC opentran (database); 現在開いているトランザクションがないことがわかりました。 ログファイルの縮小を妨げているのは何ですか？どうすれば解決できますか？
1
DBCC CheckDBはどのような種類の破損を見逃すことができますか？
この質問は、この以前の投稿と、次のように復元された将来の調査のためにデータベースを提出したことによって促されました。 BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'. Error: 3043, Severity: 16, State: 1. リンクされた質問とDBCC PAGE調査の準備ができているバックアップでは、DBCC CHECKDBはエラーなしで合格しましたが、破損が明らかに存在します。 CHECKDBはパスするがBACKUP WITH CHECKSUMは失敗することにより、どのような種類の破損が発生する可能性がありますか？
1
SHRINKFILEの失敗-ファイルサイズを大きくすると解決するのはなぜですか？
SHRINKFILEファイルグループ内の小さな不要なファイルをクリーンアップするために、いくつかの操作を実行しています。縮小の1つについて、以下のコマンドはエラーになります。 DBCC SHRINKFILE (N'myfile' , EMPTYFILE)' データベースID xのファイルID xは、別のプロセスによって縮小されているか、空であるため縮小できません 空ではなく、縮んでもいない。現在私以外の誰も使用していないデータベースで実行されています。自動縮小は有効になっておらず、一度も有効になりませんでした。ただし、それが問題になる場合は、私が手に入れる前に、このデータベースで定期的に手動で縮小が行われていました。 でSQLServerCentral、十年前からのスレッドがあることがあるため、ファイルに数MBを追加提案し、「それは今シュリンクの途中ではありません、それを伝える内部カウンタまたはスイッチをリセットします。」 これはうまくいった-素晴らしい。しかし、SQL Serverの内部に関してこれがどのように/なぜ機能するのか、誰でも詳細に説明できますか？
2
セカンダリデータファイルを削除しています。DBCC SHRINKFILE：作業テーブルページであるため、ページを移動できませんでした
に対して作成したセカンダリデータファイル（.ndf）が多すぎますtempdb。余分なファイルを削除するには、ファイルを空にする必要があります（コンテンツは他のファイルに移動されます）。 DBCC SHRINKFILE('tempdbfile8', EMPTYFILE); 次にファイルを削除します。 ALTER DATABASE tempdb REMOVE FILE tempdbfile8; しかし、EMPTYFILEコマンドはエラーを返します： DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page. Msg 2555, Level 16, State 1, Line 2 Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation. …
1
SQL Serverベースラインテストの手順の決定的なリスト？
SQL Serverを使用するアプリのパフォーマンステスト/ベースラインを実行する前に、インスタンスを再起動せずにインスタンスを「クリーン」な状態に設定できるようにしたいと考えています。私は従う傾向があるステップがありますが、正しい順序であり、冗長なステップがない決定的なリストを作成したいと思います。 この手順の一覧では、SQL Serverを「クリーン」な状態に設定できますか？ シーケンスは論理的/正しいですか？ 余分な手順はありますか？ CHECKPOINT -- Write all dirty pages DBCC DROPCLEANBUFFERS -- All should be clean after checkpoint? DBCC FREEPROCCACHE -- Clear the plan cache DBCC FREESYSTEMCACHE -- Is this necessary after FREEPROCCACHE? DBCC FREESESSIONCACHE -- May not be necessary if distributed queries aren't used, but want …
1
奇妙な動作DBCC Shrinkfile
データの95％がアーカイブおよび削除されているデータベースに対して、1 GBのチャンクでdbcc圧縮ファイルを実行しようとしています。9GBがデータ/インデックスである235GBファイルを使用しています。これを50GBに縮小したいと思います。データベースファイルの圧縮は悪いことです。断片化などが発生します。データのパージ/圧縮の一部として、idnexスクリプトを再構築することもできます。 自分のワークステーション（クアッドコア、12GB RAM、2 x SATAドライブ）のデータベースに対してdbcc圧縮ファイルスクリプトを実行すると、圧縮に約8〜10分かかります。 データベースポストデータパージの同じコピーに対して同じコードを実行すると、テスト環境（80以上のコア、128GB RAM、SSD SAN）では、70分かかります。注目すべきは、縮小ファイルの実行時にこのサーバーでアクティビティがほとんどないことです。同じ結果で4回実行されました。 次に、別のアプローチをとり、残りの9GBを別のファイルグループと物理ファイルに移動しました。自分のワークステーションで空の230GBファイルに対してdbccrinkfileを実行して50GBに圧縮すると、1分未満かかります。 これと同じアプローチで、テスト環境では、70分以上かかります。 テスト環境での70分間の実行中に、Brent Ozarのスクリプトに従って前後に待機統計のスナップショットを撮りました。下の上位3行： 秒単位のサンプル時間秒単位のサンプル期間wait_type待機時間（秒）待機数待機あたりの平均ミリ秒 2013-05-28 11：24：22.893 3600 WRITELOG 160.8 143066 1.1 2013-05-28 11：24：22.893 3600 CXPACKET 20.9 13915 1.5 2013-05-28 11：24：22.893 3600 PAGELATCH_EX 11.1 443038 0.0 Windowsイベントログに異常は何も表示されません。私はこの時点でスクラッチに向かっています。スタンドアロンワークステーションと比較して、忍者ハードウェアでこれほど時間がかかるのはなぜですか。
2
2つのDBCC INDEXDEFRAGコマンドをそれぞれ異なるテーブルで同時に実行できますか？
現在、SQL Server 2005データベースのすべてのテーブルに対して、一度に1つのテーブルに対してDBCC INDEXDEFRAGを実行するスクリプトを実行しています。スペースの制約と稼働時間の要件により、INDEXDEFRAGの代わりにDBCC DBREINDEXを使用することはできません。 特定のテーブルが最適化されるまでに長い時間がかかることに気づきました。たとえば、 "sys.dm_exec_requests"動的管理ビューを調べると、table_idが829610394であるテーブルのクラスター化インデックスで、次のINDEXDEFRAGが現在削除されていることがわかります。 DBCC INDEXDEFRAG（0、829610394、1） デフラグプロセスが完了するまでにはかなりの時間がかかることは承知しています。現在実行中のスクリプトが最終的にすべてのテーブルを最適化するという事実は別として、現在のコマンドの実行中に別のテーブルのクラスター化インデックスで別のDBCC INDEXDEFRAGを手動で実行することに害はありますか？これを行うと、両方のテーブルが実際に同時に最適化されますか？
1
トレースフラグ1222が機能していませんか？
同様に構成された2つの2008r2 SQL Server "A"と "C"を使用する顧客サイトがあります。両方のサーバーで、トレースフラグ1204および1222が有効になり、DBCC tracestatus両方のサーバーで次のように表示されます。 TraceFlag Status Global Session 1204 1 1 0 1222 1 1 0 3605 1 1 0 Aでは、トレースフラグは期待どおりに機能し、デッドロックが発生すると、エラーログに1204と1222の両方のデッドロックレポートが記録されます。ただし、Cでは、1204レポートのみが表示され、1222レポートは取得されません。 私の人生では、この違いの理由はまったくわかりません。私はこれを広範囲にグーグルで調べ、これらのトレースフラグに関するMSドキュメントを読んだ（そして再度読んだ）ので、このような動作のレポートも、何が原因であるかについてのヒントも見つかりません。近づく唯一のことは、どちらのトレースフラグも機能していないという時折の主張ですが、これらはすべて、有効化コマンドにタイプミスがあった場合のケースであることが判明しました。DBCC TRACESTATUSを使用して確認しているため、これは当てはまりません。 そのため、トレースフラグ1222 のみが機能しない原因となる可能性のある原因、および/またはそれを修正する方法についての洞察は、高く評価されます。 さて、ここに興味深い展開があります。自分でデッドロックを生成するたびに（このコードを使用：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock）、両方のトレースレポートがエラーログに記録されます。デッドロックレポートの1つのみをトリガーするように見えるのは、アプリケーションから数日ごとに発生する「自然な」デッドロックだけです。これが役立つかどうかはわかりませんが、トレース1222が1204と同じデッドロック状態のすべてについて報告しないと考える理由はありますか？
2
postgresqlのデータベース整合性チェッカー
PostgreSQLにDBCC（データベース整合性チェッカー）コマンドはありますか？SQLサーバーのDBCCコマンドは見つかりましたが、Postgresは見つかりませんでしたか？postgresqlにはパフォーマンス調整の機能が組み込まれており、postgresで使用できるDBCCコマンドはないことを読みました。本当ですか？
1
グローバルフラグを指定したDBCC TRACEON
SQL Server 2005デッドロックシナリオのトラブルシューティングの質問で、DBCC TRACEON (1204, -1)デッドロックをグローバルに追跡するためにを使用する提案がありました。 BOL でこのコマンドについて読むとき、ユーザーまたはアプリケーションがシステム上でステートメントを同時に実行していないときにのみ使用する必要があることを示しています。このトレースフラグを有効にするときは、シングルユーザーモードにする必要があるということですか。そしてさらに、なぜそれが必要であり、アドバイスに従うことが重要ですか？（常に稼働している実動システムでは、従うのが少し難しいようです。）
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.