タグ付けされた質問 「sql-server-2008」

SQL Server 2008(メジャービルドバージョン10.00.xxxx)。また、sql-serverでタグ付けしてください。

2
SQL Server 2008でインデックスを強制的にメモリに保持する方法はありますか?
数百万行のテーブルがあり、そこからクエリを時々実行する必要があります。通常、最初のクエリは非常に遅くなり(約10秒)、その後のクエリは通常、かなり高速になります(約1秒)。数時間後、遅い/その後速いサイクルが再び始まります。 必要なすべてのインデックスが存在し、適切に使用されていることを実行プランで確認しました。パフォーマンスの違いは、インデックスが後続のクエリのために実際にメモリ内にあるためであると思います(私は正しいですか、それとも他にもあります)考えられる原因?) また、インデックスを使用して他の多くのクエリも実行していますが、これらのクエリは時間がかかりませんし、そのパフォーマンスはそれほど重要ではないため、これらのインデックスが実際に重要なインデックスをメモリキャッシュから押し出しているのではないかと心配しています。 「RAMを追加する」という明らかな修正とは別に、インデックスをメモリに強制的に戻すためにダミークエリを1時間ごとに実行するスクリプトを作成することを考えていました。 これを行うよりエレガントな方法はありますか?SQLServerに、1つの単一のインデックスをキャッシュするだけの十分なメモリがある場合、それをキャッシュする必要があることを示唆する方法と同様に、 私は通常、そのようなことに関してSQLServerを台無しにするのが最善ではないことを知っていますが、私のクエリの異常な性質(非常にまれに実行されますが、タイムクリティカル)は、それが理にかなっていると信じています(可能な場合) 。 また、特定の時点でどのインデックスがメモリにキャッシュされているかを知る方法があるかどうか知りたいです。

2
IsolationLevel.ReadUncommittedで発行された共有ロック
IsolationLevel.ReadUncommittedを使用すると、クエリでロックが発行されないはずです。しかし、これをテストすると、次のロックが表示されました。 Resource_Type:HOBT Request_Mode:S(共有) HOBTロックとは何ですか?HBT(ヒープまたはバイナリツリーロック)に関連する何か? なぜまだSロックを取得するのですか? 分離レベルのスナップショットオプションをオンにせずにクエリを実行するときに、共有ロックを回避するにはどうすればよいですか? SQLServer 2008でこれをテストしていますが、スナップショットオプションはオフに設定されています。クエリは選択のみを実行します。 SQL Serverがロッククエリでそれを表示していないようですが、Sch-Sが必要であることがわかります。それでも共有ロックが発行されるのはなぜですか?による: トランザクション分離レベルの設定(Transact-SQL) READ UNCOMMITTEDレベルで実行中のトランザクションは、他のトランザクションが現在のトランザクションによって読み取られたデータを変更するのを防ぐために、共有ロックを発行しません。 だから私は少し混乱しています。

2
ディストリビューターのミラーリング
ディストリビューションデータベースのミラーリングに成功した人はいますか?ディストリビューターとして専用サーバーがあります。製品からレポートまでのすべてのプッシュレプリケーションを処理します。ディストリビューターがクラッシュした場合に備えて、すぐに同じサーバーを構築したいと考えています。誰かがこのようなものを構築することに成功しましたか?


3
トランザクションログはSQL Serverで自動的に縮小されますか?
SQL ServerデータベースがSIMPLEモードの場合、トランザクションログのバックカップを気にする必要はありません。ただし、SIMPLEモードでは、FULLモードと同様にトランザクションログが大きくなるようです。ある時点で自動的に切り捨てられますか?それとも手動で切り詰める必要がありますか?

1
SQL Server 2008R2での統計の自動更新:多数の行の挿入にもかかわらず、一部の統計が古くなっているのはなぜですか?
遅いクエリの調査中に、実行プランが非常に最適ではないように見えました(推定実行回数が1であるシークの900万回の実行をネストしたループ)。実際に古くなっているいくつかの関連する統計を確認したので、統計を再構築し、パフォーマンスの問題が効果的に解決されました。 このデータベースでは、統計の自動更新が有効になっています(デフォルトでオン)。20%+ 500行の変更(更新/挿入/削除)に基づく自動統計更新のしきい値があることを理解しています。このしきい値は、複数のインデックスで大幅に超えているようです。そのため、(A)自動更新に問題があるか、(B)オンラインで見つけた以上の更新方法があります。ドキュメンテーション。 統計を更新するようにスケジュールされたタスクを設定できることを感謝します。これは他の解決策が見つからない場合に採用するアプローチである可能性が高いですが、そのような大量の変更によってトリガーされない理由について混乱します一部の統計情報の自動更新-スケジュールされたタスクで更新する必要がある統計情報を判断するのに役立つ理由を理解する。 追加のメモ: 1)この問題は、負荷テストによってデータが作成されており、大量のデータが短時間で追加されるデータベースで指摘されたため、自動更新が定期的に(たとえば、1日に1回)発生した場合ほとんどの場合、これにより、観察された動作の一部が説明される場合があります。また、負荷テストはデータベースに大きな負荷をかける傾向があるため、負荷が高いときにSQLが統計の更新を延期しているのでしょうか(その後、何らかの理由で統計が更新されていません)。 2)連続するINSERT、SELECT、およびDELETEステートメントを含むテストスクリプトでこの問題を再現しようとすると、問題は発生しませんでした。ここでの違いは、これらのステートメントがそれぞれSQLステートメントごとの多くの行に影響を与えるのかどうか疑問に思っていますが、負荷テストスクリプトは行を個別に挿入する傾向があります。 3)問題のDBは、「単純」復旧モデルに設定されています。 いくつかの関連リンク: 実行時間の遅いクエリを分析するためのチェックリスト 統計を使用してクエリのパフォーマンスを向上させる 私はマイクロソフトコネクトを介してこの問題を提起しました: 統計の自動更新:多くの統計が古くなっています 2011年6月30日更新: さらなる調査では、しきい値レベル(たとえば、500行+ 20%)を超えて古くなっている統計は、問題のあるクエリで使用されていない統計であるため、クエリを実行すると更新される可能性がありますそれらを必要とします。クエリで使用される統計情報は、定期的に更新されています。残りの問題は、比較的少数の挿入(たとえば、推定数が1だった場合に前述の900万個程度のシークを引き起こす)の後で、これらの統計がクエリプランオプティマイザーに著しく誤解を与えることです。 この時点で私の問題は、問題は主キーの選択の不備に関連していることです。キーはNEWID()を使用して作成された一意の識別子であり、これにより非常に迅速にフラグメント化されたインデックスが作成されます-特にSQLのデフォルトのフィルファクターとしてサーバーは100%です。私の直感は、比較的少ない行の挿入後、どういうわけか統計の誤解を招く結果になり、統計を再計算するためのしきい値を下回ることです。インデックスを途中で再構築せずに大量のデータを生成したので、これはおそらく問題ではない可能性があります。したがって、不十分な統計は、結果として生じる非常に高いインデックスの断片化の結果である可能性があります。SQL Serverのメンテナンスサイクルを負荷テストに追加して、長期間にわたる実際のシステムのパフォーマンスをよりよく理解する必要があると思います。 更新2012-01-10: 考慮すべきもう1つの要素。SQL Server 2005に2つのトレースフラグが追加され(2008年にも引き続き存在するようです)、古い統計情報や誤解を招く統計情報の発生に関連する特定の欠点に対処します。問題のフラグは次のとおりです。 DBCC TRACEON(2389) DBCC TRACEON(2390) MSDN:Ian JoseのWebLog:昇順のキーと 昇順の列での自動クイック修正統計統計、Fabiano Amorim これらのフラグが有害な影響を与える可能性があるため、これらのフラグを有効にすることを決定するときはもちろん、非常に注意する必要があります。

4
大きなテーブルでの結合の最適化
2億5000万件のレコードを持つテーブルにアクセスしているクエリからさらにパフォーマンスを引き出そうとしています。実際の(推定ではない)実行プランを読んだところ、最初のボトルネックは次のようなクエリです。 select b.stuff, a.added, a.value from dbo.hugetable a inner join #smalltable b on a.fk = b.pk where a.added between @start and @end; 関連するテーブルとインデックスの定義については、下を参照してください。 実行計画は、ネストされたループが#smalltableで使用されていること、およびhugetableに対するインデックススキャンが480回(#smalltableの各行に対して)実行されていることを示しています。これは私には逆に思えるので、代わりにマージ結合を使用するように強制しようとしました: select b.stuff, a.added, a.value from dbo.hugetable a with(index = ix_hugetable) inner merge join #smalltable b with(index(1)) on a.fk = b.pk where a.added between @start and @end; …

4
SQL Serverで長時間実行されるクエリを監視する最良の方法は何ですか?
データベースに対して、かなり長時間実行されるクエリ(インデックスの再構築、大量のデータセットの更新)を実行する必要があります。SQL Server Management Studioでクエリを実行し、1時間ごとにクエリをチェックする方法はありますか?完了したらメールまたはメッセージを送信したいのですが、これに最適なツールがわかりません。

1
TDEによるデータベースミラーリング
いくつかのデータベースをミラーリングし、透過的なデータ暗号化(TDE)を使用する必要があります。データは「休止」状態で暗号化する必要があるためです。 プリンシパルとミラーの両方にTDEをセットアップしました。2つのデータベースのミラーリングを設定しているときに問題が発生します。TDEを使​​用しているため、GUIを介してミラーリングをセットアップする方法がわからないため、t-sqlを使用してジョブを実行する必要があります。 以下は、ミラーサーバーで使用したコードです --Restore the full backup to the mirrored mdf and ldf OPEN MASTER KEY DECRYPTION BY PASSWORD = '1Password' RESTORE DATABASE TDE FROM disk = '\\SERVERNAME\SQL_Stuff\Backup\TDE_FULL.bak' WITH NORECOVERY, REPLACE, MOVE 'TDE' TO 'E:\TDE.mdf', REPLACE, MOVE 'TDE_log' TO 'G:\TDE.ldf' CLOSE MASTER KEY GO --Restore the log backup to the …


2
SQL-SERVER 2008リンクサーバー経由でOracleのCLOB列を読み取れないのはなぜですか?
SQL-Server 2008からOracle 11gデータベースのデータにアクセスしたい リンクサーバーを設定し、実行時に select * from [Link_server_name]..Oracle_schema.Oracle_table Oracle_tableにはNumber列とvarchar2列が含まれ、すべて例外として機能します。 しかし、Oracle_tableにCLOB列が含まれていると、次のエラーが発生します。 Der OLE DB-Anbieter 'MSDAORA'fürden Verbindungsserver 'L_V407SR8T' hat die Meldung 'Unspecified error'zurückgeben。 Der OLE DB-Anbieter 'MSDAORA'fürden Verbindungsserver 'L_V407SR8T' hat die Meldung 'Oracleエラーが発生しましたが、エラーメッセージをOracleから取得できませんでした。zurückgeben。 Der OLE DB-Anbieter 'MSDAORA'fürden Verbindungsserver 'L_V407SR8T' hat die Meldung 'Data type is not supported。' zurückgeben。 メッセージ7306、レベル16、状態2、行1 ダイ「 "MCCAPP"。 "DOGGRUPPEN"」-Tabelle …

3
一般に、データベースの行のすべての変更の記録はどのように保存されますか?
私が取り組んでいるプロジェクトでは、さらに監査またはロールバックするために、データベースの一部のテーブルの行に対するすべての変更を追跡する必要があります。その行を誰がどのIPアドレスからいつ変更したかを簡単に見つけ、以前のバージョンを復元できる必要があります。 同様のものが、たとえばStack Exchangeでも使用されています。他の人の質問を変更すると、自分が変更したことがわかり、変更をロールバックできます。 現在のスキーマが平均的なビジネスアプリとほとんど同じプロパティ(以下)を持っている場合、オブジェクトのすべての変更をデータベースに格納するために使用される一般的な手法は何ですか? オブジェクトのサイズは比較的小さいです。nvarchar(1000)たとえば、バイナリデータの巨大なblobはなくても、ディスクに直接保存され、Microsoft SQL ではなく直接アクセスされる場合がありますfilestream。 データベースの負荷はかなり低く、データベース全体はサーバー上の1つの仮想マシンによって処理されます。 以前のバージョンへのアクセスは、最新バージョンへのアクセスほど高速である必要はありませんが、それでも最新の状態¹であり、遅すぎない必要があります²。 <tl-dr> 次のようなケースを考えましたが、そういうシナリオはあまり経験がないので、他の人の意見を聞いてみました。 IDとバージョンで行を区別して、すべてを同じテーブルに格納します。IMO、それは深刻な愚かであり、パフォーマンスレベルで遅かれ早かれ傷つけるでしょう。このアプローチでは、最新のアイテムとバージョントレースに異なるセキュリティレベルを設定することも不可能です。最後に、すべてのクエリを記述するのはより複雑になります。実際、最新のデータにアクセスするには、IDですべてをグループ化し、各グループで最後のバージョンを取得する必要があります。 1つのテーブルに最新バージョンを保存し、変更のたびに、古いバージョンを別のスキーマの別のテーブルにコピーします。欠点は、変更されていなくても、常にすべての値を保存することです。変更された値をに設定することnullは解決策ではありません。値がに、nullまたはに変更されたときにも追跡する必要があるためnullです。 最新バージョンを1つのテーブルに保存し、変更されたプロパティのリストと以前の値を別のテーブルに保存します。これは、二つの傷のようだ:最も重要なのは同じ列に以前の値の異質なタイプをソートする唯一の方法は持っているということですbinary(max)。2つ目は、以前のバージョンをユーザーに表示するときに、このような構造を使用するのがより困難になると私は考えています。 前の2つのポイントと同じことを行いますが、バージョンを別のデータベースに保存します。パフォーマンスに関しては、同じデータベースに以前のバージョンを置くことで最新バージョンへのアクセスが遅くなるのを避けるために興味深いかもしれません。それでも、これは時期尚早の最適化であり、同じデータベースに古いバージョンと最新のバージョンを置くことがボトルネックであるという証拠がある場合にのみ実行する必要があると思います。 </ tl-dr> ¹たとえば、HTTPログの場合と同様に、ログファイルに変更を保存し、サーバーの負荷が最も低い夜間にログからデータベースにデータをフラッシュすることはできません。異なるバージョンに関する情報は、すぐに、またはほぼすぐに入手できる必要があります。数秒の遅延は許容範囲です。 ²情報へのアクセスはそれほど頻繁ではなく、特定のユーザーグループのみがアクセスしますが、バージョンのリストが表示されるまで30秒間待つように強制することはできません。この場合も、数秒の遅延は許容されます。

6
予測されるデータベースの増加を見積もる
私は最近、DBA研修生としてSQL Server 2008を使い始めました。データベースのサイズを計算する必要がありますが、最近の数か月間のデータベースの成長と、今後12か月の予測される成長も予測します。 sp_spaceusedステートメントを使用して実際のサイズを計算できますが、他のすべてをどのように計算しますか?

5
テーブルのスキーマを指定する必要のないクエリ
SQL Server 2000から2008データベースに一連のテーブルをインポートしました。インポートされたすべてのテーブルには、ユーザー名のプレフィックスが付いていますerpadmin.tablename。 テーブルのプロパティでは、dbスキーマとして「erpadmin」がリストされています。クエリを作成するときは、「erpadmin」を含める必要があります。混乱を招くすべてのテーブル名の前。 現在の結果: select * from erpadmin.tablename 望ましい結果: select * from tablename


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.