データベース管理者

データベースのスキルを向上させ、コミュニティの他の人から学びたいデータベースの専門家向けのQ&A

3
IDENTITY値をリセット
IDENTITY列のあるテーブルがあります。開発中に、時々行を削除し、再度追加します。しかし、IDENTITY値は常に増加し続け、それらを再度追加したときに1から始まっていませんでした。私のIDは68から> 92になり、これによりコードがクラッシュします。 IDENTITY値をリセットするにはどうすればよいですか？
1
SQL Server nvarchar（max）vs nvarchar（n）はパフォーマンスに影響します
これはSQL Server 2008 R2 SP2です。2つのテーブルがあります。どちらも同じです（データとインデックス）。ただし、最初のテーブルにはVALUE列がnvarchar(max)あり、2番目のテーブルにはと同じ列がありnvarchar(800)ます。この列は、非クラスター化インデックスに含まれています。また、両方のテーブルにクラスター化インデックスを作成しました。インデックスも再構築しました。この列の最大文字列長は650です。 両方のnvarchar(800)テーブルに対して同じクエリを実行すると、一貫して高速になり、何倍も高速になります。確かに、「varchar」の目的を無効にしているようです。テーブルには800,000行以上が含まれます。クエリでは、約110,000行（これが計画の推定値）を確認する必要があります。 io統計によると、lobの読み取りはないため、すべてが並んでいるように見えます。実行計画は同じですが、2つのテーブルのコストの割合にわずかな違いがあり、推定行サイズが大きいnvarchar(max)（91バイト対63バイト）ことを除いて。読み取り回数もほぼ同じです。 なぜ違いがあるのですか？ =====スキーマ====== CREATE TABLE [dbo].[table1]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [ProductID] [bigint] NOT NULL, [ProductSkeletonID] [bigint] NOT NULL, [Value] [nvarchar](max) NOT NULL, [IsKeywordSearchable] [bit] NULL, [ValueInteger] [bigint] NULL, [ValueDecimal] [decimal](18, 2) NULL, [ValueDate] [datetime] NULL, [TypeOfData] [nvarchar](20) NOT NULL, CONSTRAINT [PK_table1] PRIMARY KEY …
7
WITH REPLACEを使用してバックアップを復元しているときのエラー3154
コンピューターにSQL 2012 SP1がインストールされています。データベースのバックアップを作成しましたtest.bak。 test2同じデータベースと同じ名前のデータベースがありますが、データが変更されました。 データベースをtest.bak介して復元したいtest2。 私は常にエラーが発生しています： エラー3154：バックアップセットには、既存のデータベース以外のデータベースのバックアップが含まれています。 私は試した： 私は右クリックしました test2 -> Restore database -> From device 選択test.bakして確認しましWith Replaceたが、エラーが発生します。 次に、右クリックしてみました test2 -> Restore file and filegroups 選択test.bakして確認しましWith Replaceたが、エラーが発生します。 古いデータベースを削除してから正しい名前でバックアップを復元できますが、SQL 2008を使用していたときは、既存のデータベースを復元しても問題はありませんでした。 SQL2012を使用しているため、このエラーが頻繁に発生するようです。
4
SQLスクリプトの実行を中断する方法
私はSQLスクリプトに取り組んでおり、いくつかの条件が満たされない場合、スクリプトの継続を停止する必要があります。 GoogleでGoogleを検索したところ、重大度が20のRaisErrorが終了することがわかりました。しかし、いくつかの理由で、私はそのオプションを使用できません。 SQLスクリプトの実行を停止する可能な代替手段を教えてください。
3
他のトランザクションをブロックするSPIDのスリープ
私が経験しているいくつかのブロッキングを追跡するのに本当に苦労しています。 ルートブロックSPIDのステータスは「sleeping」、cmdは「AWAITING COMMAND」、およびはsqltextですSET TRANSACTION ISOLATION LEVEL READ COMMITTED。 [ブロックされたトランザクション数別の上位トランザクション]レポートを表示すると、ブロックSQLステートメントは「-」です。 SQLでトレースを実行し、ルートブロッキングSPIDをトレースしてブロッキングが発生した場合、実際にはどこにも導かれていません。最後のtraceステートメントは同じであるsqltext以上SET TRANSACTION ISOLATION LEVEL READ COMMITTED。 関連するすべてのストアドプロシージャをチェックして、それらにTRY / CATCH BEGIN TRAN / COMMIT TRAN / ROLLBACK TRANステートメントがあることを確認しました（すべてにストアドプロシージャを使用しているため、スタンドアロンのステートメントは実行されません）。この問題は過去24時間に発生し始めたばかりで、システムに変更を加えたと主張する人はいません。 解決策：めったに使用されないストアドプロシージャの1つに挿入のエラーがありました（列の数が一致しませんでした）が、正確に何が起こっているのかまだ混乱しています。 すべてのトレース情報を確認すると、このストアドプロシージャのEXECステートメントが時々リストされましたが、ブロックするSPIDでBLOCKが発生する直前には決してありませんでした。ブロックを開始すると、トレースはその実行（またはその中のステートメントのいずれか）を記録しなかったようです。ただし、トレースがその実行を記録し、ブロッキングが発生しなかった場合もあります。 ストアドプロシージャのエラーレポートはユーザーから送信されたものであり、トレースで複数のEXECステートメントを見つけてSSMSで実行することができました。それらを実行したとき、ブロッキングが発生したりハングしたりすることはありませんでした。それらは期待通りに実行されました（catchブロックが起動し、エラー後にトランザクションをロールバックしました）。ストアドプロシージャの修正を解決した後、問題は再び発生していません。
2
WHERE句で変数を使用しないようにする方法
次のような（簡略化された）ストアドプロシージャがある場合： CREATE PROCEDURE WeeklyProc(@endDate DATE) AS BEGIN DECLARE @startDate DATE = DATEADD(DAY, -6, @endDate) SELECT -- Stuff FROM Sale WHERE SaleDate BETWEEN @startDate AND @endDate END Saleテーブルが大きい場合、SELECTローカル変数が原因でオプティマイザが最適化できないため、実行に時間がかかる可能性があります。SELECT変数を使用してパーツを実行し、日付をハードコードし、実行時間を約9分から約1秒にテストしました。 「固定」日付範囲（週、月、8週など）に基づいてクエリを実行する多数のストアドプロシージャがあるため、入力パラメータは@endDateのみで、@ startDateはプロシージャ内で計算されます。 問題は、オプティマイザを危険にさらさないために、WHERE句の変数を避けるためのベストプラクティスは何ですか？ 私たちが思いついた可能性を以下に示します。これらのベストプラクティスのいずれか、または別の方法がありますか？ ラッパープロシージャを使用して、変数をパラメーターに変換します。 パラメーターは、ローカル変数と同じようにオプティマイザーに影響しません。 CREATE PROCEDURE WeeklyProc(@endDate DATE) AS BEGIN DECLARE @startDate DATE = DATEADD(DAY, -6, @endDate) EXECUTE DateRangeProc @startDate, @endDate …
2
無期限のWAITFORを起動すると、ログファイルのサイズが増加しますか？
アプリの前回のリリースでは、Service Brokerキューに何かが到着したときに待機するように指示するコマンドを追加しました。 WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM MyQueue) DBAは、追加以来、ログサイズが屋根を通過したことを教えてくれました。これは正しいですか？それとも私は他の場所を探すべきですか？
1
expire_logs_days paramを更新してSQLを再起動した後、古いbinlogは削除されますか？
MySQL 5.1.x | InnoDB | ウィンドウズ mysqlデータディレクトリがbinログでいっぱいになり始めています。 現在、Windows mysqlサーバーで次の設定を構成しています。 [mysqld] log-bin server-id=1 binlog-do-db=foodb1 binlog-do-db=foodb2 expire_logs_days=25 expire_logs_days設定をexpire_logs_days=10mysqlサービスに変更してバウンスする予定です。この変更を行ってからどれくらい経ってから、古いビンのログが明らかになると思いますか。 これは、夜間にスケジュールされたタスクの一部としてのみ実行されますか？または、これはすぐにすべきですか？
6
表から「n」個の連続した無料番号を見つける
このような数字のテーブルがあります（ステータスはFREEまたはASSIGNEDです） id_set番号ステータス ----------------------- 1 000001割り当て済み 1 000002無料 1 000003割り当て済み 1 000004無料 1 000005無料 1 000006割り当て済み 10007割り当て済み 1 000008無料 1 000009無料 1 000010無料 1 000011割り当て済み 1 000012割り当て済み 1 000013割り当て済み 1 000014無料 1 000015割り当て済み 「n」個の連続した番号を見つける必要があるため、n = 3の場合、クエリは 1 000008無料 1 000009無料 1 000010無料 各id_setの最初の可能なグループのみを返す必要があります（実際、クエリごとにid_setに対してのみ実行されます） 私はWINDOW関数をチェックしてCOUNT(id_number) OVER (PARTITION BY id_set ROWS UNBOUNDED PRECEDING)いましたが、のようなクエリをいくつか試しましたが、それだけでした:) …
2
一時テーブルでvarcharサイズは重要ですか？
ストアドプロシージャの一時テーブルのvarchar(255)すべてのvarcharフィールドに使用することについて、妻の仕事について議論があります。基本的に、一方のキャンプは定義が変更されても常に機能するため255を使用し、もう一方のキャンプは潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持したいと考えています。 パフォーマンスキャンプは正しいですか？他に影響はありますか？彼らはSQL Serverを使用しています。
3
SQL Server NTFSアロケーションユニットサイズ
SQL Server 2008 R2を実行しているWindows 2008 R2では、DISK IOのパフォーマンスに対するNTFSアロケーションユニットサイズはどれほど重要ですか。ミッションクリティカルなアプリ用に数台のサーバーを構築したサーバー管理者は、NTFSアロケーションユニットサイズ（クラスターサイズ）をデフォルトの64 KBではなく4 KBのままにしたようです。SQLサーバーは既にインストールされています。 SQLをアンインストールするために苦労する価値はありますか？64 KBのクラスターサイズでドライブをフォーマットし、SQLサーバーを再インストールしますか？
2
多対多および弱いエンティティ
別のエンティティに定義されない限り存在できないエンティティがあり、このエンティティを多対多の関係に参加させたい。 例：アーティストにはアルバムがあり（アルバムはアーティストなしでは存在できません）、アルバムにも多くのトラックがありますが、同じトラックが多くのアルバムに存在する可能性があります。 そのため、アルバムとトラックの間には多対多の関係があります。 アルバムが弱いエンティティである場合、その主キーはアーティストを参照する外部キーであるため、多対多の関係を表す別のテーブルへの外部キーにすることはできません。 問題は、SQLでこのような関係を持つことは可能ですか？その場合、どのように表現するのですか？
2
PostgreSQLインデックスキャッシング
PostgreSQLでのインデックスのキャッシュ方法に関する「わかりやすい」説明を見つけるのが難しいので、これらの仮定のいずれかまたはすべてを現実的にチェックしたいと思います。 行のようなPostgreSQLインデックスはディスク上に存在しますが、キャッシュされる場合があります。 インデックスは完全にキャッシュ内にある場合とまったくない場合があります。 キャッシュされるかどうかは、それが使用される頻度に依存します（クエリプランナーが定義）。 このため、ほとんどの「賢明な」インデックスは常にキャッシュに置かれます。 インデックスbuffer cacheは行と同じキャッシュ（？）に存在するため、インデックスで使用されるキャッシュスペースは行で使用できません。 これを理解する動機は、データの大部分が決してアクセスされないテーブルで部分インデックスを使用できると示唆された別の質問に続いています。 これを実行する前に、部分インデックスを使用すると2つの利点が得られることを明確にしたいと思います。 キャッシュ内のインデックスのサイズを小さくし、キャッシュ内の行自体により多くのスペースを解放します。 Bツリーのサイズを小さくして、クエリの応答を高速化します。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.