SQL Server のメモリ管理 – Part 3

神谷 雅紀SQL Server Escalation Engineer   以下に続く、SQL Server のメモリ管理の第 3 回目です。 SQL Server のメモリ管理 – Part 1 SQL Server のメモリ管理 – Part 2   バッファプール内の領域の用途とそのサイズ   バッファプールは、サイズが 8KB の「ページ (page)」と呼ばれる領域に論理的に分割されています。バッファプールのコミットされている領域のサイズ (以降では、これを単に「バッファプールのサイズ」と呼びます) は、パフォーマンスカウンタ Buffer Manager – Total pages により確認することができます。1 ページは 8KB であるため、このカウンタの値を 8 倍することで、バッファプールの KB 単位のサイズを算出することができます。 データベースファイルのコピーイメージ、言い換えれば、キャッシュしているデータベースのデータは、すべてバッファプール内に置かれます。そのサイズは、パフォーマンスカウンタの Buffer Manager – Database pages により確認することができます。 SQL Server:Buffer Manager…

9

[Power BI] ※緊急告知※ Power BI (無料版) のサービス内容が 2017 年 6 月 1 日に変更されます。

SQL Server Developer Support Team 米内 満   ※ お詫びと修正 ※ 6 月 5 日更新 ———————————————————————————————————————————— -お詫び- 6 月 1 日以降に表示される [12 ヵ月のオファーリング] の内容について、ご利用されている環境により、実装内容が異なることを確認致しました。 その影響により、日本では、アップデート後も [12 ヵ月のオファーリング] が表示されず、2 ヵ月後のトライアルが表示される動作となり、 そのトライアルが終了した段階で、[12 ヵ月のオファーリング] が表示される実装となっておりました。 この度は、当初のご案内と異なる実装となり混乱を招きましたこと、謹んでお詫び申し上げます。   -修正- この度の動作について、非常に多くのご要望、ご意見を頂き、開発部門にフィード バックいたしました。 それに伴い、先週末に開発部門にてアップデートがなされ、当初の予定通り、12 ヵ月のオファーリングが表示されるように実装いたしました。 現在、2 ヵ月の評価期間中であっても、[12 ヵ月のオファーリング] を受けることが可能です。   表示される画像 ————————————————————————————————————————————   ※ 重要 ※  2017 年 6 月 2…

8

DO’s&DONT’s #10: やらない方がいいこと – クエリの条件句で変数を参照する

神谷 雅紀 Escalation Engineer   クエリの WHERE 句や JOIN ON 句など、クエリのフィルタ条件や結合条件で変数を参照すると、クエリのパフォーマンスが悪化する (実行時間が長くなる) 可能性が高まります。   なぜ?   必ずしも最適ではない実行プランが生成される可能性 SQL Server は、クライアントから送信されてくるバッチ (クライアントから送信されてくるひとつ以上のステートメントの塊) をコンパイルし、バッチ内の各ステートメントの実行プランを生成し、その後、そのバッチを実行します。実行プランの生成過程であるクエリの最適化 (optimization) では、クエリの検索条件や結合条件などを参照し、最も低コストであると考えられる実行プランを選択します。クエリの検索条件や結合条件は、実行プランの選択に大きな影響を与えます。しかし、変数は、最適化の段階では未知の値です。 以下の例を見てみます。 declare @x nvarchar(10) set @x = N’ABC’ select * from tab where col1 = @x go このバッチは、declare, set, select の 3 ステートメントから構成されています。このバッチの実行が要求されると、まず、これら 3 ステートメントがコンパイルされます。select については、実行プランが生成されます。この実行プランの生成時、@x の値は未知です。なぜならば、@x の値が決定するのは、バッチのコンパイルおよび select の最適化が終わって、実際にこのバッチが実行され、set ステートメントが実行完了した後だからです。select…

5

バックアップが存在しない、または、バックアップからのリストアが行えない場合のデータベース復旧手順

  データベースが破損しエラーが返されたり、アクセスできないといった状況が発生した場合、バックアップからリストアするという対処がもっとも一般的かつ確実な対応であり、SQL Server サポートでは、通常、バックアップからのリカバリ手順をご案内しております。 しかしながら、バックアップを採取していなかったり、バックアップからのリストアに失敗したという場合もあります。 今回は、そのようなバックアップからのリストアが行えない場合のデータベースの修復方法を紹介します。 ※ 注意事項 ※ 以下の手順は検証済みの手順ですが、必ずしもデータベースの復旧を保証しているものではありません。手順の実施につきましては、自己責任において行ってください。 データベースの破損状況によっては、以下で紹介する修復手順を実施しても、データベースに接続でき、アプリケーションが実行できるまでの状態に復旧できない場合もあります。その場合はデータベースの再作成が必要となります。 本手順を実施すると、トランザクションの一貫性が失われる場合があります。トランザクションの一貫性が保たれているかどうかの確認は、対象データベースに格納されているデータ間の関連性を熟知している方、もしくは、この手順を実施する方の責任において実施する必要があります。トランザクションの一貫性が保たれているかどうかの確認が行えない場合には、この手順を実施しないで下さい。 また、SQL Server サポートサービスにて、可能な限りデータベースを復旧するサポートを承っております。必要に応じてご利用下さい。     ■修復手順 1. 対象データベースのファイルコピーを行います。 SQL Server サービスを停止し、対象データベースファイルのファイルバックアップ(別フォルダにデータベースファイルをコピー)を行います。 データベースファイル、ログファイルのファイルパスは以下のクエリにて確認可能です。以降の手順で予期しない問題が発生した場合、このファイルを用いて手順 1. の状態まで戻すことができます。バックアップ完了後、SQL Server サービスを再起動します。 select d.name as databasename,f.name as filename ,f.physical_name as filepath from sys.master_files f,sys.databases d where d.database_id = f.database_id GO 2. Microsoft SQL Server Management Studio を起動し、sa 等の管理者権限をもつ sysadmin ロールメンバとして…

4

HowTo: Management Studio を使ってトランザクションログファイル (ldf) のサイズを小さくする方法

神谷 雅紀 Escalation Engineer 「ログファイルが大きくなってディスク領域を圧迫し始めているので、ファイルサイズを小さくしたい」という内容の問合わせは今でも多く寄せられます。今回は、SQL Server Management Studio GUI を使って、トランザクションログファイルのサイズを小さくする手順を紹介します。 ここに記載した方法で、トランザクションログファイルのサイズを小さくしたいという状況のほとんどに対応可能だと思います。 ここに記載した方法でトランザクションログファイルのサイズを小さくできない場合は、おそらく、トランザクションログファイルのサイズを小さくする前に、レプリケーションやミラーリングのトラブルシューティングなどが必要になるでしょう。 ステップ 1 : データベースの復旧モデルを確認する 復旧モデルが「単純」かそれ以外かによって、以降の手順が違ってきますので、まず最初に、データベースの復旧モデルを確認します。 手順 復旧モデルを確認するために、データベースのプロパティを表示します。データベースのプロパティは、オブジェクトエクスプローラでデータベース名を右クリックし、「プロパティ」をクリックすることで表示できます。 表示されたダイアログボックスの左ペインで「オプション」を選択すると、右ペインに「復旧モデル」が表示されます。復旧モデルは、「単純」「完全」「一括ログ」のいずれかです。 ステップ 2 : トランザクションログをバックアップする トランザクションログは、データベースファイルへの更新履歴ですので、データベースに対して更新を行うたびにトランザクションログファイルには履歴データが記録され、何もしなければ、トランザクションログファイル内の履歴データはどんどん増えていきます。 復旧モデルが「単純」の場合は、トランザクションログファイル内のデータ量が一定量を超えると、SQL Server がファイルの中身を消し、ファイル内に空き領域を作り、空いた領域は再利用されます。 一方、復旧モデルが「完全」または「一括ログ」に設定されている場合は、過去に一度でもデータベースの完全バックアップ (データベースフルバックアップ) を取得していると、SQL Server はファイルの中身を消すことはしませんので、トランザクションログファイル内のデータは、バックアップしなければ削除されません。 このステップ 2 は、復旧モデルが「完全」または「一括ログ」の場合のみ行います。「単純」の場合は、次のステップ 3 に進みます。 手順 データベースを右クリックし、「タスク」 –  「バックアップ」をクリックします。 「バックアップの種類」として「トランザクションログ」を選びます。もし、復旧モデルが「単純」に設定されている場合は、「トランザクションログ」は選択できません。 「バックアップセットの有効期限」は既定のまま、「バックアップ先」は、バックアップデータを書き込むファイル名を指定します。「ディスク」を指定して、「追加」でファイル名を指定して下さい。そのサーバーにテープデバイスがある場合には、「テープ」を選んでも構いません。 最後に「OK」を押すと、バックアップが開始されます。 復旧モデルが「完全」または「一括ログ」であっても、データベースの完全バックアップが一度も取得されていない場合、トランザクションログのバックアップは以下のエラーで失敗します。 メッセージ 4214、レベル 16、状態 1 現在、データベースのバックアップが存在しないので、BACKUP LOG を実行できません。 復旧モデルが「完全」または「一括ログ」であっても、データベースの完全バックアップが一度も取得されていない場合は、トランザクションログは自動的に切り捨てられていますので、このステップを実行せずにステップ 3…

4

どうする? SQL Server のクエリ パフォーマンスが低下した!

  アプリケーションの応答が急に遅くなった、バッチ処理がいつもの時間に終わらない・・・ クエリのパフォーマンスが低下し早急に対処が必要な場合に、まずお試しいただきたいことをまとめました。 まずは 1 を実施してパフォーマンスが改善されるか確認し、ダメなら 2 または 3 へ進んでください。 1. 統計情報を更新する 統計情報を最新の状態にすることで、現在のデータ分布に最適な実行プランが選択されるようになる可能性があります。 a) データベース単位で実行        sp_updatestats どのクエリを実行しても遅い、どのオブジェクトの統計情報を更新したらよいのかわからない、という場合にお試しください。 ステートメント) —————————- USE <データベース名>; GO EXEC sp_updatestats; —————————- 使用例) —————————- USE mydatabase; GO EXEC sp_updatestats; —————————- sp_updatestats (Transact-SQL) http://msdn.microsoft.com/ja-jp/library/ms173804.aspx   b) テーブル単位 or インデックス単位で実行     UPDATE STATISTICS 特定のクエリが遅いとわかっている場合にお試しください。 ステートメント) —————————- USE <データベース名>; GO UPDATE STATISTICS <テーブル名 or…

3

[SSRS] Reporting Services 文字化け:異なる OS 間の PDF 文字化け

森  隆博SQL Developer Support Engineer 皆さん、こんにちは Reporting Services を使用していて、文字化けに遭遇したことはありませんか?文字化けが発生する状況はいくつかパターンがありますが、今回はレポートからエクスポートした PDF が文字化けしているという現象について記載します。   シナリオ 以下のような環境を想定してください。 ・Reporting Services が稼動しているマシン:Windows XP や Windows Server 2003・ブラウザを起動してレポートを表示するクライアントマシン:Windows Vista や Windows 7、Windows Server 2008 この様な場合、レポート表示後、エクスポートした PDF が文字化けすることがあります。   なぜ文字化けが発生するのか? ここでは説明の簡略化のため、仮称として Windows Server 2003 や Windows XP 等を 旧 OS 環境、Windows Vista や Windows 7、Windows Server 2008 を新 OS 環境と呼びます。 旧 OS…

2

DO’s&DONT’s #8: やってはいけないこと – インデックス再構築 (REBUILD) 後のインデックス統計情報更新 (UPDATE STATISTICS)

神谷 雅紀 SQL Server Escalation Engineer   DO’s&DONT’s #7: やらない方がいいこと – インデックス再構築 (REBUILD) 後のデータファイル圧縮 (SHRINK) で、インデックス再構築後のデータベース圧縮を話題にしましたが、似たようなものとして、インデックス再構築後のインデックス統計情報更新があります。 インデックス再構築後に、再構築したインデックスの統計情報を更新すると、それは意味がないか、統計情報の精度を落とします。   なぜ?   DO’s&DONT’s #7: やらない方がいいこと – インデックス再構築 (REBUILD) 後のデータファイル圧縮 (SHRINK)  でも触れていますが、インデックスの再構築によりインデックスは再作成されます。インデックスが再構築される時、同時にそのインデックスの統計情報も作成されます。ここで作成される統計情報は、データサンプル率 100% で作成されます。インデックス作成時には、すべての行が読み取られるため、その読み取られた行を使って、同時に統計情報も作成されるためです。 これは、テーブルにデータがある状態で、新規にインデックスを作成した場合も同様です。 この状態で再度統計情報を更新することは、仮に 100% のサンプル率で更新したとしても、同じことを繰り返す分だけ無駄です。また、統計情報の更新 (UPDATE STATISTICS や sp_updatestats の実行) を行う時、統計を作成するために参照されるデータは、明示的にサンプル率 100% と指定していない限り、既定では、ランダムに読み取られた少数のデータです。ある程度大きなテーブルでは、テーブル全体の行の数パーセントです。せっかく全データを使って作成された統計情報を破棄してまで、少数のデータで統計情報を作り直す必要はありません。サンプルデータは多い方が精度の高い統計になります。 尚、インデックス再構築によって更新される統計は、更新対象インデックスの統計であって、それ以外の統計 (更新対象ではないインデックスや列の統計) は更新されません。   実際に見てみましょう       use tempdb go –…

2

デッドロックを避けるコツ

神谷 雅紀SQL Server Escalation Engineer   まずは、デッドロックとは?から   デッドロック (deadlock) とブロッキング (blocking) は異なる事象です。   デッドロックは、リソース獲得において、A が B を待たせ、かつ、B が A を待たせている状態です。例えば、トランザクション 1 がある行に排他ロックを獲得している状態でトランザクション 2 がその行に共有ロックを獲得しようとします。この時点では、トランザクション 1 がトランザクション 2 を待たせているだけであるため、発生している事象は、デッドロックではなくブロッキングと呼ばれる事象です。この状態から、トランザクション 1 が別の行に共有ロックを獲得しようとし、その行にトランザクション 2 が排他ロックを持っていると、デッドロックと呼ばれる事象が発生します。このデッドロックはサイクルデッドロック (cycle deadlock) と呼ばれます。     デッドロックは、お互いがお互いを待っている状況であるため、第三者が介在しない限り、その状況から脱することはありません。SQL Server では、Deadlock Monitor が第三者となり、この状況を検出し、解消する役割を担っています。   デッドロックは、複数のブロッキングから構成され、第 3 者が介在しない限り、継続します。 ブロッキングは、ロックを保持しているトランザクションが終了することでロックが解放されれば、第 3 者の介入がなくても自然解消します。   ロックはどこに獲得されるのか?   ロックは、クエリの最終結果に含まれる行やキーだけに獲得される訳ではありません。  …

2

バックアップからのリストアによるリカバリ手順

みなさん、こんにちは。今回は バックアップからのリストアによる SQL Server のリカバリ手順についてご紹介します。 本手順では SQL Server 2012 を使用して、下記 の2 通りのリカバリ手順について記載しています。   A. 障害発生直前までのリカバリ手順   B. ある特定の時点までのリカバリ手順  ■前提条件  障害発生直前、またはある特定の時点までデータベースを復旧するためには、下記 の 3 つの条件を満たしていることが必要です。    1. 完全バックアップを取得済みであること。   2. トランザクション ログが破損していないこと。   3. データベースの復旧モデルが「完全」であること。   ※ 本手順は ServerA という名前のサーバー上にインストールされた SQL Server の test データベースについて、2013 年  9  月 18 日に下記のバックアップを取得済みであることを前提として記載しています。  No 時間 バックアップの種類 バックアップ ファイル名  1 02:00…

2