Introduction Two things that fascinate me most about SQL Server is Memory and Transaction log. The more I try to demystify them the more complex they become. I am writing this article to bring nit bits of SQL Server memory and how to understand its various concepts. I would try to reach every aspect of memory superficially but will make sure important points are not missed out. I have tried keepin
質問 2009年7月6日月曜日 4:38 こんにちは。 以前はお世話になりました。今回もわからないことがありきました。 今年2月から運用を開始して約5ヶ月になりますが、突然SQLServerが使えなくなりました。 サーバーにインストールしてあるManagement Studioで接続しようとしてもできませんでした。 その後構成マネージャを使ってSQLServerを再起動したら使えるようになりました。 イベントビューアを見たら、SQLServerが使えなくなった時刻に リソース モニタ (0xbcc) のワーカー 0x000000008000C1C0 が、ノード 0 で応答を停止している可能性があります。 解放されたメモリ: 39496 KB。CPU の概算使用量: カーネル 93 ミリ秒、ユーザー 62 ミリ秒、間隔: 60015。 というものがありました。 SQLServerログを見たら
Using PSSDiag and SQL Nexus to monitor SQL Server performance How to use SQLDiag, SQLNexus and PAL tools to analyze performance issues in SQL Server SQL パフォーマンス チューニング 中上級編 vol. 3 SQLDiag / SQL Nexus ツールの利用 (前編) SQL パフォーマンス チューニング 中上級編 vol. 3 SQLDiag / SQL Nexus ツールの利用 (後編) で紹介されていますが、SQL Server の情報を取得するためのツールとして、SQLDiag というツールがあります。 SQL Server をインストールした環境であれば SQLDiag も導入されているはずですので、このツールを使用することで、
本連載の最終回となる今回は、データベースの論理障害をテーマとして取り上げます。データベースエンジニアの仕事としては、これまでの連載で紹介してきたデータベース設計について取り上げられることが多いのですが、論理障害を含むデータベース運用設計は、システムの設計開発より圧倒的に長い保守運用期間を乗り切るために非常に重要な工程です。 今回のタイトルからも連想されるとおり、当初は「さまざまな方法で本当にデータベースを壊して障害状態を観察し、そこからの復旧作業を疑似体験する」というデータベースの物理障害からの復旧、いわゆるバックアップとデータベースリカバリを予定していました。 しかし、近々のハードウェア事情を見ると、高性能化、低価格化が進み、安価に冗長性を持った環境を用意できるようになり、ハードウェア障害が直接データベース障害の原因になるケースが少なくなりました。また、OSやDBMSなどのソフトウェアの
SQL Server の各種情報を取得するための 3 種類の情報を公開させていただきました。 SQL Server の各種情報を時系列で取得するためには、パフォーマンスモニターを利用するのが一般的ですが、どのようなカウンターをとればよいのかの情報を、SQL Server パフォーマンスカウンター として公開しています。 SQL Server の動的管理ビュー (DMV) を使用した、詳細な情報の取得については、Gist で公開しています。 パフォーマンスモニターで取得できない、詳細な情報についてはこちらのクエリで取得することができます。 これらの情報をどのように使用するかを、ここからはじめる SQL Server の状態取得 として公開しています。 パフォーマンスモニターや DMV の情報は取得するだけではなく、解析が必要です。 その解析の最初の一歩となる方法について、こちらの情報でまと
案件の概要 社内のメーリングリストに「SQL Serverプロセスがメモリリークしていて、調査を助けてほしい。」というメールがとんできました。よく読んでみると、どうやら、過去に私が担当したことのあるお客様の環境のようです。私がお手伝いしたのはSQL Server 2000からSQL Server 2005へのアップグレードプロジェクトでしたが、つい数カ月前にその環境をSQL Server 2012へアップグレードしたとのこと。そして、最近になってSQL Serverプロセスのメモリ - private bytes - が右肩上がりに増えていることに気がついたらしいのです。 private bytesが右肩上がりに増えるということは… さて、SQL Server プロセスのprivate bytesが右肩上がりに増えると、なぜSQL Serverがリークしているということになるのでしょう?お
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く