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

PostgreSQL 9.2.2（Windows 32ビット）にはpg_restore、チェックポイントの頻度に関するログ警告を体系的に表示するコマンドがあります。たとえば： LOG: checkpoints are occurring too frequently (17 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". データベースのサイズは約3.3 Gbで、112テーブル/ 160ビューで、約14分で復元できます。 それが中に発生するのは正常pg_restoreですか？

14 postgresql  restore  configuration  checkpoint 

長い話ですが、私たちの長期コンサルタント（元従業員）は、Tivoli Storage Managerとのインターフェースを取るためにカスタムスクリプトを数年（2006年ほど）書いており、という名前のSQL Server DBオプションをチェックしているようtruncate log on checkpointです。彼らの主張は、SQL 2012であるインスタンスでスクリプトが機能し、バックアップを実行することを妨げているということです。 私はそのようなオプションを見つけることができずsp_configure、バックアップが1つのインスタンスを除いてどこでも機能しているので、それは完全なBSだと感じています。しかし、それがそうであるなら、私は地雷を取り除き、他の時代遅れの要素を取り除きたいと思います。ベンダーに確認してもらっていますが、彼らの言うことにはあまり自信がありません。 私が行った調査では、SQL 2000またはSybaseのオプションの1つであると考えられます。もう1つの主張は、復旧モデルがSIMPLE存在し、それをオンまたはオフにする明示的なオプションがない場合、それが以降のバージョン（2008以降）で暗黙的に呼び出される/使用されるというものでした。 TRUNCATE LOG最近のトランザクションログのしくみが原因でこのコマンドは廃止されているため、現時点ではクエリを実行できるオプションではないと思います。 私はSQL Server 2000のインスタンスを持っていないので、誰かがこれを思い出したり、置いてあるものでそれをチェックしたりできることを望んでいました。それは私が推薦できるものではないことを彼らに話しました。私はまた、誰かがこれが時代遅れであることを確認できることを望んでいました。

11 sql-server  sql-server-2012  transaction  log  checkpoint 

古いオールフラッシュアレイから新しいオールフラッシュアレイ（異なるが、確立されたベンダー）に移行すると、チェックポイント中にSQL Sentryで待機が増えることがわかりました。 バージョン：SQL Server 2012 Sp4 私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2,500で約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。歩哨は私たちをPAGEIOLATCHワティスにもっと向けます。独自の分析を行うと、PAGEIOLATCH and PAGELATCH待機の組み合わせのようです。Perfmonを使用すると、一般に、チェックポイントを行うページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです（主に挿入/更新）。 ストレージベンダーは、ファイバーチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、HBAキューの問題であるとは考えていません。また、ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1 TBに変更せずに増やしました。チェックポイントプロセス中に、2〜4個のコア（16個のうち）が100％に急上昇しますが、全体的なCPUは約20％です。BIOSも高パフォーマンスに設定されています。興味深いことに、CPUがC2スリープ状態になっているのは無効にしたにもかかわらず、通常はC2スリープ状態であるため、スリープ状態がC1を超えた理由を調査しています。 ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部のSPIDが同じページで待機していることもわかります。データベースの設計には、いくつかの挿入ホットスポットがありますが、同じ設計が古いストレージに配置されていました。 このクエリのループを100回実行すると、ディスクとメモリで待機しているSPIDの数を把握できました。 SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100 「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。SIOSデータキーパーを無効にする（これが古いストレージで行われている場合でも）。異なるHBAブランド。 exec sp_Blitz @outputtype = 'markdown' 優先度5：信頼性：-危険なサードパーティモジュール-Sophos Limited-ソフォスのバッファーオーバーラン保護-SOPHOS〜2.DLL-危険と思われるサードパーティモジュールがインストールされています。 優先度200：情報：-クラスターノード-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117がグローバルに有効になります。-トレースフラグ1118がグローバルに有効になります。-トレースフラグ3226がグローバルに有効になります。 優先度200：ライセンス：-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 …

9 sql-server  sql-server-2012  storage  waits  checkpoint 

完全復旧モデルを使用しているデータベースを想定して、SQL Serverでレコードが（INSERT/ UPDATEなどによって）書き込まれると、先読みロギングにより、データページを変更する前に変更がログファイルに書き込まれることが保証されます。 ログとデータページの両方のエントリがRAMに作成され、後でチェックポイントによってディスクにコミットされます。 システムクラッシュ（議論のために電力損失）が発生した場合、RAMの内容がシステムの再起動後も存続しないため、ダーティページ（RAMで変更されてもディスクにコミットされないIEデータ）はどうなりますか？ ？ 編集 いくつかのテストの後、ダーティページが失われていないことがわかりますが、理由はわかりません。 このチュートリアルを使用して テストデータベースを作成する CREATE DATABASE DirtyPagesDB GO USE DirtyPagesDB GO 自動チェックポイントをオフにする DBCC TRACEON(3505, -1); DBCC TRACESTATUS(); テーブルを作成し、データを挿入して、チェックポイントを発行します。 CREATE TABLE t1 (Speaker_Bio CHAR(8000)) GO INSERT INTO t1 VALUES ('SQL'),('Authority') GO CHECKPOINT ダーティページがないことを確認する -- Get the rows of dirtied pages SELECT database_name = d.name, OBJECT_NAME …

8 sql-server  checkpoint