「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-戻る([[SQL Server>SQL Server#i20a1481]]、[[大量データの処理方式]])
-[[戻る>SQL Server#i20a1481]]([[SQL Server 問題の分析方法]])

--[[障害>SQL Server#va76dbd2]]
---[[SQL Server の障害復旧]]

--[[性能>SQL Server#fb124d93]]
---[[DBMSのロック・分離戦略と同時実行制御]]
---[[SQL Server でのロック・タイムアウト]]
---[[SQL Server のロックのエスカレーション]]
---[[SQL Server でのデッドロック]]
---SQL Server 大量データ処理時の性能問題
---[[SQL Server アドホック クエリ問題の監視]]
---[[SQL Server 結合方式の問題を監視する]]

* 目次 [#l01418b0]
#contents

*概要 [#p778f957]

*詳細 [#p42ac813]

**先ず、統計情報の更新 [#x20e2843]
大量データ処理時の性能問題は、以下で解決する可能性があります。

-[[SQL Server のアップグレードと移行]]の[[データ変換方式>SQL Server のアップグレードと移行#te3a1a2a]]でも説明していますが、~
データの大量追加・大量更新の後に統計情報の更新を行うことで解決する可能性があります。~
(これを行わない場合、検索SQLで不適格なプランが使用され性能が出ない事があります)

--UPDATE STATISTICS (Transact-SQL)~
http://msdn.microsoft.com/ja-jp/library/ms187348.aspx
--sp_updatestats (Transact-SQL)~
http://msdn.microsoft.com/ja-jp/library/ms173804.aspx

**トランザクション ログ モード [#z43f2f72]

***完全復旧モデル [#jca3371d]
全てのトランザクションが、「トランザクション ログ」に記録されるため遅い。

***一括ログ 復旧モデル [#z227f3e5]
-特定の大規模な操作を除いた、全てのトランザクションが記録される。
-「特定の大規模な操作」とは「[[bcpユーティリティ、BULK INSERT>SQL Server のアップグレードと移行#pa8ed940]]・SELECT INTO、Index系)」などになる。

***単純復旧モデル [#i4a9862f]
-トランザクションが記録されない(正確には、チェックポイント後に不要なログは削除される)。
-「ログバックアップ不可 → ポイントインタイム復旧不可 → データ損失リスク大」と言うデメリットがある。

**データベースの拡張 [#yd353562]
データベースの自動拡張によって一時的な性能劣化が発生する可能性があります。

***トランザクション ログ ファイル [#te75472e]
-使用可能なログ領域を超える領域を必要とするトランザクションを実行し、~
そのデータベースのトランザクション ログの自動拡張オプションを有効にしている場合、

--トランザクションの完了までにかかる時間には、構成されたサイズずつ~
トランザクション ログを拡張するのにかかる時間が含まれます。

--増加量が多い場合、または長時間かかる他の要因が存在する場合、~
タイムアウト エラーが原因で、トランザクションを開くクエリが失敗することがあります。

***データ ファイル [#bb6a4215]
-データベースのデータの一部の自動拡張が原因で同様の問題が発生する可能性があります。


***tempdb [#w8683c43]
-必要に応じて、tempdb ファイルの自動拡張を許可します。~
これによって、ディスクがいっぱいになるまで、ファイルを拡張できるようになります。
>注:自動拡張操作の間に発生する可能性があるアプリケーションのタイムアウトを許容できない~
運用環境の場合、予測されるワークロードを許容するための領域を事前に割り当てます。

-tempdb データベース ファイルの拡張単位が小さすぎることのないように、~
ファイル拡張の増分値を妥当なサイズに設定します。

-tempdb に書き込まれたデータ量と比較してファイルの拡張単位が小さすぎると、~
tempdb を頻繁に拡張する必要が生じる場合があります。

-このことは、パフォーマンスに影響します。


**結論 [#u818ea97]
-自動拡張は有効にして(拡張されないと読み取り専用になる)、
-拡張単位は割合ではなく(頻繁に拡張されない)適切な値を設定する。
-可能であれば、使用状況を監視して、これらを事前に拡張する様に運用する。

**参考 [#p062edbf]
-データベースの拡張~
http://msdn.microsoft.com/ja-jp/library/ms176037.aspx
-tempdb のパフォーマンスの最適化~
http://msdn.microsoft.com/ja-jp/library/ms175527(v=sql.105).aspx
-[INF] SQL Server における自動拡張および自動圧縮の構成に関する注意事項~
http://support.microsoft.com/kb/315512/ja
-SQL に関する Q&A データベースの圧縮、拡張、および再設計など~
http://technet.microsoft.com/ja-jp/magazine/ff808322.aspx

*参考 [#x49eb094]
-[[SQL Server 問題の分析方法]]

-[[SQL Server のオプティマイザ]]
--[[実行計画の確認、統計情報のメンテナンスの手順>SQL Server のオプティマイザ#c61f8f07]]
--[[統計情報の自動更新・手動更新の使い分け>SQL Server のオプティマイザ#i28f44ee]]

-[[SQL Server パーティション分割]]

----
Tags: [[:データアクセス]], [[:SQL Server]], [[:障害対応]], [[:性能]]

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS