Embed Size (px)
Citation preview
SQL SERVER FORSHAREPOINT指南
December 13th 2014Mayumi Mitaki
Advanced Solution Co,Ltd Manager
自己紹介
SharePoint歴
2007年以前
某SIerグループ会社に所属。Windows Server OS,SQL Server の製品評価、サポート、導入案件を担当。
2007年 SharePoint2007に初めて触る。2007製品評価、サポートを担当。Windows Server,MSFC,SQL Serverの導入構築も継続。
2008年2009年
2007製品評価、サポート、構築案件のリーダーを担当する。OS,MSFC,SQL,SharePointをまとめて設計、構築するチームとして案件を手掛ける。
2010年2011年
2007に加えて、2010製品評価、サポート、構築案件のリーダーを担当。新規構築、移行案件などで、数千ユーザー～数万ユーザー規模のファーム構築、コンテンツ移行、バージョンアップ移行を手掛ける。
2012年 某SIerグループ会社から某HW大手ベンダー系列の会社へ。SharePoint2010/2013システムの提案を担当。
2013年～
某HW大手ベンダー系列の会社からアドバンスド・ソリューション株式会社へ電撃移籍(笑)現在、数社のSharePoint2013インフラ構築の設計と技術支援を担当。
三瀧 真由美(みたき まゆみ)
アドバンスド・ソリューション株式会社 マネージャー
SharePoint Serverインフラの設計と技術支援を担当しています。
趣味は、着物を着て、落語や狂言を観たり、京都に行ったり、
呑み会に行ったり、美味しいものを作ったり食べたりすることです。
着物を着ていない日も、同じことをします(笑)
facebookは、食べ物と愛猫達の画像がほとんどです。
たまに横浜や旅行先での風景をアップしたりします。
運動が苦手なのですが、水泳とヨガはやっています。
でもヨガだけでは痩せないから、呑み会で摂取したカロリーを
消費するために、まじめに運動しないといけない今日この頃。
(水泳は時間がとれないので休止中。)
ちなみに姉御とか蟒蛇とかよく言われるのですが、そんなことないです！
・・・という感じですが、よろしくお願いします。
SQL SERVER FOR SHAREPOINT指南とは？
▪ 周知のとおり、SharePoint Serverの各種データはSQL Serverに格納されています。
▪ なので、SQL Server が動いてないと、SharePoint Server は何もできません。
▪ つまり、SharePoint Serverにとって、SQL Serverはとても重要な存在なのです。
▪ でも、とりあえずSQL Serverが動いていれば、SharePoint Serverも動いてしまうから、
▪ SQL Serverの設定は既定のままで放置になりがちです。
▪ そんな見落とされがちなSharePoint Server ファームで動くSQL Serverのあれこれを
▪ ご紹介いたします。
▪ といっても基本的なことなので、知っていることばかりでしたらゴメンナサイ！
▪ マイクロソフトがクラウドファースト路線を突き進む中で、時代遅れでニッチなネタですが
▪ AzureでSharePointファームを運用する際にもしかしたら役にたつかも？
本日のお題目
▪ SQL Server とは？
▪ SQL Server for SharePointの目的
▪ まずはSQL Serverのサイジング
▪ SharePoint2013のデータベース
▪ コンテンツデータベース
▪ SQL Server システムデータベース
▪ tempdb
▪ ディスクサイズ
▪ トランザクションログファイル
▪ データベースファイル
▪ 復旧モデル
▪ トランザクションログファイルの肥大化を防ぐ
▪ ファイルサイズの確認方法
▪ ファイルサイズを小さくする
▪ データベース以外でのあれこれ
▪ SharePointのデータベースメンテナンス
▪ SQLから直接参照できるSharePointデータベース
▪ まとめ
SQL SERVERとは？
▪ (今更ですが)SQL Server はマイクロソフト社のリレーショナルデータベース製品です。
▪ SQL Server 6.0から始まり、2014年12月時点での最新バージョンはSQL Server 2014です。
▪ SharePoint ServerとSQL Serverはそれぞれバージョンでの組み合わせが決まっています。
▪ 本資料はSharePoint Server 2013がサポートするSQL Server(2008R2,2012,2014)の情報をベースにしています。
▪ 基本的な考え方はいずれのバージョンでも同じです。
SharePoint Server SQL Server
2003 7.0/2000
2007 2000SP4/2005SP1/2008/2008R2
2010 2005SP3/2008SP1/2008R2
2013 2008R2/2012/2014
SQL SERVER FOR SHAREPOINTの目的
▪ 今回、SQL Server のあれこれを理解する目的は何でしょう？
▪ 1つ目はSQL Serverのサイジングや設定を適切にして、SharePoint Serverが動き始めてから、SQL Serverが遅くならないようにすることです。
▪ 2つ目は、ディスクのエコ。
SQL Serverがたくさん使うディスクを有効に使いまわすための設定や運用について、
基本的な方法を理解します。
▪ 3つ目は、運用が始まってからSQL Serverを見守り、メンテナンスする方法です。
運用監視ツールを使って監視することがひとつの方法ですが、SQL Server が
もっているツールを使って、SQL Serverの状態を確認する方法を整理します。
▪ スペシャルテクニックや、Enterpriseな使い方については、またいつか・・・。
(というか、どなたか教えてくださいｗ)
まずはSQL SERVERのサイジング
▪ 考えることが多いSQL Serverのサイジング！
▪ 台数はインスタンスの分け方に準じて決めるから後まわしにして、まずはCPUとメモリから。
SQL SERER サーバーサイジング
▪ 下記のマイクロソフト情報を基にSQL Serverのサーバーサイジングについて整理してみましょう。
▪ SharePoint 2013 のハードウェア要件およびソフトウェア要件
▪ http://technet.microsoft.com/ja-jp/library/cc262485(v=office.15).aspx
▪ SharePoint 環境内の SQL Server の概要 (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/ff945791(v=office.15).aspx
▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013) http://technet.microsoft.com/ja-jp/library/cc298801.aspx
▪ SharePoint Server ファーム内の SQL Server のベストプラクティスhttp://technet.microsoft.com/ja-jp/library/hh292622.aspx
▪ データベースの種類と説明 (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/cc678868(v=office.15).aspx
SQL SERVERのCPUとメモリを決める (中規模展開)
まずはtechnetで紹介されている中規模展開について
▪ 中規模展開(1,000 ～ 10,000 ユーザー)の場合、8コア が最小値
▪ 中規模展開(1,000 ～ 10,000 ユーザー)の場合、メモリは16GBが最小値
▪ データベースサイズが最大2TBの場合、メモリは32GBが推奨値
▪ データベースサイズが最大4TBの場合、メモリは64GBが推奨値
コア数、メモリを減らす場合の条件
▪ 最小値の8コアより減らした場合、SQL Serverの処理能力が低下し、SharePointの処理も低下する可能性がある。
▪ データベースの役割とサイズによってSQL Server のインスタンスとサーバーをわけることで、1台あたりのCPUとメモリを抑える。
▪ SQL Serverの処理速度はCPUとメモリにかなり依存します。
▪ できるだけ推奨値以上にしてください。
SQL SERVERのCPUとメモリを決める (小規模展開)
ユーザー1,000以下の小規模展開でのサイジングは？
▪ CPUは4コア以上、できれば8コア
▪ メモリは8GB以上、できれば16GB
ユーザー数人のテスト環境のサイジングは？
▪ CPUは2コア以上
▪ メモリは4GB以上
SharePoint ServerとSQL Serverを1台のサーバーで動かす場合は？
▪ CPU4コア、メモリ6GB以上は欲しいですね。
▪ SQL Serverはメモリ食いでメモリを占有しがちなので、SQL Serverの設定で
メモリの上限を2GBにして、SharePoint Serverや 他のアプリケーションも
メモリを使えるようにしましょう。
SQL SERVERのインスタンス数と台数を決める
▪ SQL Server 1インスタンスにすべてのデータベースを保持する場合の台数は1台です。
▪ 大規模環境でデータベースのサイズが大きくなる場合は、インスタンスを増やして
データベースを分散し、インスタンスを実行するサーバーも増やすことで
SQL Serverに無理をさせずに処理をさせます。
▪ さて、インスタンスとデータベースをどのようにわけたらよいでしょうか？
SHAREPOINT2013のデータベース構成とサービスアプリケーション(STANDARD機能)
種類 データベース名 サイズ傾向
Configuration database SharePoint_Config Small(≧1GB)
Central Administration content database
SharePoint_AdminContent_<GUID> Small(≧1GB)
App Management database AppManagement Small(≧1GB)
Business Data Connectivity database
Bdc_Service_DB_<GUID> Small(≧1GB)
Secure Store database Secure_Store_Service_DB_<GUID> Small(≧1GB)
Usage and Health Data Collection database
WSS_Logging※SharePoint_Logging、
Extra large(1TB≦)
Subscription Settings database
SettingsServiceDB Small(≧1GB)
Word Automation Services database
WordAutomationServices_<GUID> Small(≧1GB)
Managed Metadata database Managed Metadata Service Application_Metadata_<GUID>
Medium(100GB≦)
Machine Translation Services database
SharePoint Translation Services_<GUID> Small(≧1GB)
※technetではSharePoint_Loggingと書かれていますが、実際はWSS_Loggingが作られます。
SHAREPOINT2013のデータベースUSER PROFILE APPLICATION
種類 データベース名 サイズ傾向
Profile database User Profile Service Application_ProfileDB_<GUID>
Medium to large(100GB≦1TB)
Synchronization database
User Profile Service Application_SyncDB_<GUID>
Medium to large(100GB≦1TB)
Social Tagging database
User Profile Service Application_SocialDB_<GUID>
Small to extra-large(1GB≦1TB≦)
SHAREPOINT2013のデータベースSEARCH SERVICE APPLICATION
種類 データベース名 サイズ傾向
Search Administration Search_Service_Application_DB_<GUID> Medium(100GB≦)
Analytics Reporting Search_Service_Application_AnalyticsReportingStoreDB_<GUID>
Medium to large(100GB≦1TB)
Crawl Search_Service_Application_CrawlStoreDB_<GUID>
Medium(100GB≦)
Link Search_Service_Application_LinkStoreDB_<GUID>
Medium to large(100GB≦1TB)
SHAREPOINT2013のデータベースコンテンツデータベース
種類 データベース名 サイズ傾向
Content database WSS_Content 200GB-4TB
Content database(個人用サイト)
WSS_Content_Personal 200GB-4TB
SHAREPOINT2013のデータベースサービスアプリケーション(ENTERPRISE機能)
種類 データベース名 サイズ傾向
Project Server ProjectWebApp Small to Medium(1GB≦100GB)
Power Pivot DefaultPowerPivotServiceApplicationDB_<GUID>
Small(≧1GB)
PerformancePoint Services PerformancePoint Service _<GUID> Small(≧1GB)
State Service SessionStateService_<GUID> Medium to large(100GB≦1TB)
SHAREPOINTデータベースを分類して分散する
▪ たくさんあるSharePoint2013のデータベースは役割から以下の5種類に分類できます。
(1)構成とサービスアプリケーション(Standard機能)
(2)User Profileサービスアプリケーション
(3)Searchサービスアプリケーション
(4)コンテンツデータベース
(5)サービスアプリケーション(Enterprise機能)
▪ この5種類を異なるインスタンス＆サーバーにわけることで、SQL Serverの負荷を分散します。
SHAREPOINTデータベースサイズの傾向
▪ SharePoint2013のデータベースのサイズを正確に算出することは難しいです。
▪ 計算式などの情報が公開されていないからです。
▪ そこでtechnetに記載されているサイズの傾向からそれぞれの合計値を予測します。
(1)構成とサービスアプリケーション(Standard機能) 10GB≦1TB
(2)User Profileサービスアプリケーション 200GB≦3TB
(3)Searchサービスアプリケーション 400GB≦2TB
(4)コンテンツデータベース 200GB≦4TB
(5)サービスアプリケーション(Enterprise機能) 100GB≦1TB
SHAREPOINTデータベースサイズの傾向
▪ 1インスタンスあたりのデータベース最大サイズが4TB以内になりました。メモリ64GBでOK！
▪ メモリ32GBの上限値である2TB以内にするためには、(3)(4)のデータベースをさらに分散させましょう。
▪ という設計をすると、最低でもインスタンスが5つ、サーバーが5台になっちゃいますね。
▪ ちなみに実際に運用してみると、サービスアプリケーションのデータベースが最大サイズまでいくことはなかなかありません。
▪ もうすこし、インスタンス(とサーバー)を集約してみましょう。
▪ (5)Enterprise機能を使わないことが多く、その場合は(1)～(4)のデータベースだけになります。
▪ 大規模環境でコンテンツと個人用サイトのサイズがそれなりになる場合は、(1)～(4)を
4インスタンスにわけて配置します。
▪ 小規模(ユーザー数1,000以下)から中規模(ユーザー数10,000以下)の場合は
さらに集約できそうです。
SHAREPOINTデータベースサイズの傾向
コンテンツはそれなりのサイズになるけど、個人用サイトは使わない場合
(1)構成とサービスアプリケーション(Standard機能)
＋User Profileサービスアプリケーション 数GB～
(2)Search サービスアプリケーション 数GB～
(3)コンテンツデータベース 200GB≦4TB
▪ ユーザー数が少なく、個人用サイトを使わない(ソーシャル機能が使えない)場合は、
User Profileサービスアプリケーションのデータベースのサイズはあまり大きくなりません。
▪ なので、構成とサービスアプリケーションのデータベースとまとめて1インスタンスにします。
▪ コンテンツがそれなりのサイズになる環境は、コンテンツデータベースも大きくなりますが
検索データベースのサイズもそれなりに大きく、I/Oも高くなることが予想されるため
可能であれば専用のインスタンスにします。
SHAREPOINTデータベースサイズの傾向
コンテンツのサイズが未知数、個人用サイトは使わない場合
(1)構成とサービスアプリケーション(Standard機能)
＋User Profileサービスアプリケーション
＋Searchサービスアプリケーション 数GB～
(2)コンテンツデータベース 200GB≦4TB
▪ コンテンツのサイズが未知数の場合は、思い切って検索データベースもスとまとめて
1インスタンスにします。
▪ コンテンツデータベースのサイズが増加して、検索データベースのサイズも大きくなってきたら
インスタンス(サーバー)を追加して、検索データベースを移動するとよいでしょう。
SHAREPOINTデータベースでのインスタンスの分け方
規模 ユーザー数 機能 構成 STD※1
UP※2
検索 コンテンツ
ENT※3
中規模大規模
1,000～1万～
個人用サイトありEnterprsei機能あり
1 2 3 4 5
中規模大規模
1,000～1万～
個人用サイトありEnterprsei機能なし
1 2 3 4 なし
中規模 1,000～1万
個人用サイトなしEnterprsei機能なしコンテンツサイズ大
1 2 3 なし
中規模 1,000～1万
個人用サイトなしEnterprsei機能なしコンテンツサイズ大
1 2 なし
小規模 ～1,000 個人用サイトありEnterprsei機能あり
1 2 1
小規模 ～1,000 個人用サイトなしEnterprsei機能なし
1 なし
開発 数人 全部あり 1
※1 Standard 機能のサービスアプリケーション※2 User Profile サービスアプリケーション※3 Enterprise機能のサービスアプリケーション
コンテンツデータベースのサイズって？
▪ コンテンツデータベースのサイズは上限200GB～4TB(一部シナリオのみ制限なし)です。
▪ でも、コンテンツデータベースってどのくらいのデータをいれると上限200GBになるの？
▪ それは使ってみないとわからない・・・というのが正直なところですが(ぉぃ)、(いちおう)計算式が公開されています。
ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013)
コンテンツ データベースのストレージを見積る
http://technet.microsoft.com/ja-jp/library/cc298801(v=office.15).aspx
データベース サイズ = ((D × V) × S) + (10 KB × (L + (V × D)))
D ドキュメント数の推定値
V ライブラリ内のドキュメントがもつバージョン数の概数
S 保存するドキュメントの平均的なサイズ
L 環境内のリスト項目の数
10KB メタデータの大きさをざっと見積もった定数
コンテンツデータベースのサイズって？
▪ 上述の式で算出できる場合は問題ないですが、どんなデータをいれるか決まっていない、
▪ あるいは予想がつかない場合はどうしたらよいでしょうか？
▪ 既存システムからのリプレースであれば、既存システムのデータを参考にしてサイズを見積りしましょう。
▪ Technetにも、「現在の成長率と使用状況に基づいて推定するほうが簡単です」と
書いてあります。
▪ 新規システムの場合は、足りなくなったらディスクを追加できる算段をつけておいたうえで、
予算と相談しながら、ディスクを用意しておきましょう。
コンテンツデータベースのサイズって？
▪ ちなみに、さきほどの式を使ったサンプルでは、グループ作業ポータルで
105GBというサイズになっています。
▪ ユーザー数1万にしては、意外とサイズが小さいような？
データベース サイズ = (((200,000 x 2)) × 250) + ((10 KB ×(600,000 + (200,000 x 2))) = 110,000,000 KBつまり 105 GB
D 200,00010,000 ユーザー × 20 ドキュメントと仮定して計算
V 2最大許容バージョン数を 10 と仮定
S 250KB
L 600,000
10KB メタデータの大きさをざっと見積もった定数
コンテンツデータベースのサイズの上限は？
▪ SQL Server はTB以上のデータベースを余裕で扱うことができます。
▪ ただし、SharePoint Serverのデータベースについてはサイズ上限の推奨値があります。
▪ コンテンツデータベースは、1データベースあたり200GBが推奨値です。
▪ 4TBあるいはそれ以上にすることも出来ますが、いろいろと条件がつきます。
サイズ上限 条件
200GB 一般的な使用シナリオコンテンツデータベース200GBの場合、ファームあたり500個(100TB)がサポートされる
4TB 一般的な使用シナリオ以下の要件が満たされる場合にサポートされる・1 GB あたり 0.25 IOPS のディスク サブシステム パフォーマンス最適なパフォーマンスを得るには、1 GB あたり 2 IOPS を用意する(推奨)
・高可用性、障害復旧、将来の容量、およびパフォーマンス テストの計画を作成する必要がある・バックアップ方法を計画する(SharePoint バックアップは正常に動作しない可能性がある)
明示的な制限なし
ドキュメント アーカイブ シナリオ以下の要件が満たされる場合にサポートされる・上限4TBの条件を満たす・"ドキュメント センター" サイト テンプレートまたは "レコード センター" サイト テンプレート・月平均5%未満の参照と1%未満の更新
コンテンツデータベースとサイトコレクションの関係
▪ ところで、コンテンツデータベースは1つ以上のサイトのデータが入っています。
▪ サイトというか、サイトコレクション単位ですね。
▪ 1つのコンテンツデータベースに1つ以上のサイトコレクションが配置されます。
▪ 1つのサイトコレクションのデータを複数のコンテンツデータベースに分散することはできません。
ということで、SharePointファームで、いくつのサイトコレクションを作るかということも、
コンテンツデータベースのサイジングに関係してきます。
▪ 1コンテンツデータベース＝1サイトコレクションの場合は、サイトコレクションはデータベースのサイズが上限になります。
▪ 1コンテンツデータベースに複数のサイトコレクションを配置する場合は、データベース＝サイトコレクションにならないので、クォータの設定をする場合は、サイトコレクションの数とコンテンツデータベースの関係を考慮してサイズを決めましょう。
▪ 1コンテンツデータベース＝1サイトコレクションにした場合、1インスタンスに複数のコンテンツデータベースを配置できますが、メモリとデータベースのサイズの関係に留意してデータベース数を決めましょう。
コンテンツデータベースとサイトコレクションの参考資料
▪ ソフトウェアの境界と制限 (SharePoint 2013) コンテンツ データベースの制限
http://technet.microsoft.com/ja-jp/library/cc262787(v=office.15).aspx#ContentDB
▪ ソフトウェアの境界と制限 (SharePoint 2013) サイト コレクションの制限
http://technet.microsoft.com/ja-jp/library/cc262787(v=office.15).aspx#SiteCollection
余談：データベースのGUIDははずせる
▪ サービスアプリケーションのデータベース名に[GUID]というものがついています。
▪ ファーム構成ウイザードを使ってサービスアプリケーションを構成すると、[GUID]が
▪ 既定のデータベース名の末尾についてきます。
▪ これが、SQL管理者からしたら、ありえないようなもので・・・
▪ SharePoint_AdminContent_4508a31f-2e01-4029-bc59-6779b8ed0e
▪ Managed Metadata Service_ef3b2a59d48e42ac90a6a79a0ada8b3d
▪ Search_Service_Application_DB_65618f8e321a43bcac535166aedb2fa8
▪ というような長～い覚えられない名前になってしまいます。
▪ 覚えられないだけでなくストアドプロシージャでデータベース名を取得するときにエラーになったります(困)。
▪ SQL管理者も困りますが、Search ServiceやMetadata Serviceを複数作ったときには、サービスアプリケーションとデータベースの関係が名前だけで判断できなくなって困ります。
余談：データベースのGUIDははずせる つづき
▪ SharePoint Server 2010から、データベース名にGUIDがつくようになり、
▪ PowerShellを使ってサービスアプリケーションを構成すればGUIDなしの
▪ データベースを作れました。
▪ でも構成ウィザードで構成するほうが楽なんですよね(^^;
▪ SharePoint Server 2013では、構成後にデータベース名からGUIDをとる方法が
▪ 公開されてました！
▪ サービス アプリケーション データベースの名前を変更する (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/ff851878(v=office.15).aspx
▪ このtechnetに各種サービスアプリケーションのデータベース名を変更する手順が書かれています。
▪ 私もまだやったことないので、いつか試してみようと思っています。以上、余談でした。
SQL SERVER システムデータベース
▪ SQL Serverのデータベースはシステムデータベースとユーザーデータベースに分類されます。
▪ SharePoint Server のデータベースはユーザーデータベースに該当します。
▪ システムデータベースは、SQL Serverを構成するデータベースです。
▪ システムデータベースは4種類あります。
データベース名 説明
master SQL Server のインスタンスに対するすべてのシステム レベル情報を記録します。ログイン、構成、およびその他のデータベースが含まれます。
model SQL Server インスタンスで作成されるすべてのデータベースのテンプレートとして使用され、model データベースに対する変更は、それ以降に作成されるすべてのデータベースにも適用されます。
msdb 通知とジョブをスケジュールするために SQL Server エージェントによって使用されます。
tempdb 一時オブジェクトまたは中間結果セット(すべての一時テーブル、一時ストアド プロシージャ、その他の一時的な保管項目)を保持します。
TEMPDB！サイズ！
▪ TemdbはSQL Serverのパフォーマンスに重要な役割を果たします。
▪ Temdbはデータの一時的な置き場でもあり、インデックスの再構築の処理を行う場所でもあります。
▪ Tempdbのサイズが大きく、I/O処理が高速なシステムは、SQL Serverの処理が速くなります。
▪ Tempdbは一時データのサイズに応じて自動拡張しますが、予め大きなサイズを用意しておくことで自動拡張の発生を防ぐと
▪ SQLはデータ処理に専念できます。
▪ Tempdbのサイズはユーザーデータベース合計値の1～10%を目安にします。
TEMPDB！サイズ！
tempdbデータベース
http://msdn.microsoft.com/ja-jp/library/ms190768(v=sql.110).aspx
tempdbのパフォーマンスの最適化
http://technet.microsoft.com/ja-jp/library/ms175527(v=sql.105).aspx
tempdbに使用するディスク領域の計画
http://technet.microsoft.com/ja-jp/library/ms345368(v=sql.105).aspx
tempdbのディスク領域の不足に関するトラブルシューティング
http://technet.microsoft.com/ja-jp/library/ms176029(v=sql.105).aspx
TEMPDB！ファイル数！
▪ Tempdbは、データベースファイルにセカンダリファイルを追加して、データベースファイルをCPU数
と同じ数にすると、処理がより速くなります。
▪ ただしCPU数が8以上のサーバーでは、とりあえず8ファイルにしておき、tempdbの負荷が
▪ 高いようであれば、4の倍数(12、16、20・・・)でファイルを増やしていきます。
▪ 1つのデータベースファイルの拡張子はmdfですが、追加したファイルの拡張子はndfです。
▪ Mdfとndfはすべて同じサイズにして、mdfとndfの合計値がtempdbのサイズになるようにします。
▪ Ex.ユーザーデータベースの合計が1TB(1,024GB)になる場合
tempdbのサイズの目安は100GB
CPU8コアなら、mdf12GB×1ファイル+ndf12GB×7ファイル=96GB
tempdbデータベースの SQL Server で割り当ての競合を減らすための推奨事項
http://support.Microsoft.com/kb/2154845/
tempdbデータファイル数を CPU 数に一致させる
http://blogs.msdn.com/b/jpsql/archive/2013/01/17/do-s-amp-dont-s-17-tempdb-cpu.aspx
データベースのサイズとディスクサイズはちょっと違う
▪ 長々とデータベースについて説明して、データベースのサイズはざっくり数GB～数TBくらいで
見積りすればいいことがご理解いただけたかと思いますが(笑)
データベースのサイズ＝データベース領域のディスクサイズではないのです。
▪ SQL Server のデータベースは、データベースファイルとトランザクションログファイルという
2種類のファイルで構成されています。2つのファイルがセットで1つのデータベースなのです。
▪ データベースのサイズはデータベースファイルのサイズを指しています。
トランザクションログファイルのサイズはこれから考えます。
▪ トランザクションログファイルが加わったデータベースサイズにさらに空き領域を追加した
サイズがディスクサイズとなります。
サイジング対象 構成要素
データベースサイズ データベースファイルサイズ＋トランザクションログファイルサイズ
ディスクサイズ データベースファイルサイズ＋トランザクションログファイルサイズ＋空き領域
トランザクションログファイルと空き領域のサイジング
▪ トランザクションログファイルのサイジングはデータベースファイルの30％を目安にします。
▪ ただし、一部のデータベースは運用中にトランザクションログファイルのサイズがデータベースファイルの数倍以上になることあります。
▪ とりあえず一律30％程度でサイジングして、設定と運用でトランザクションログファイルのサイズを制御していきます。
▪ 空き領域は、データベースファイルとトランザクションログファイルが想定より大きくなる場合に使用するための領域です。
▪ 空き領域もファイルサイズの25～30%がマイクロソフトの推奨値です。
SharePoint Server ファーム内の SQL Server のベスト プラクティス
事前にデータおよびログ ファイルの増加を管理する
http://technet.microsoft.com/ja-jp/library/hh292622(v=office.15).aspx
Ex.データベースファイルが1GB、トランザクションログサイズ30%、空き領域30%の場合
データベースサイズ1.3GB
データベースファイルサイズ1GB＋トランザクションログファイルサイズ0.3GB
ディスクサイズ1.7GB
データベースファイルサイズ1GB＋トランザクションログファイルサイズ0.3GB＋空き領域0.4GB
データベースファイルとトランザクションログファイル
▪ データベースファイルは、ユーザーが更新するデータが書き込まれて保持されます。
▪ トランザクションログファイルは、データベースファイルへの変更処理のログが書き込まれます。
▪ データベースファイルは読み取りと書き込みの処理が発生します。
▪ トランザクションログファイルは書き込み処理が発生します。
▪ 読み込みと書き込みの両方があるならデータベースファイルのほうが処理が多そうですが、トランザクションログの書き込み処理が圧倒的に多いです。
▪ そのため、データベースファイルとトランザクションログファイルを別ドライブ(ディスク)に
▪ わけて配置すると、それぞれのI/O処理が分散されて処理が速くなります。
▪ 既定ではどちらも同じパスに配置されますが、SQL Serverのインストール時のパラメータ設定や
インストール後にインスタンス設定を変更することで配置する場所は変えられます。
▪ 既定のパスに配置された場合も手動で移動できます。
データベースファイルとトランザクションログファイルの配置
▪ データベースファイルとトランザクションログファイルを別ドライブ(ディスク)に配置するだけでなく、データベースも種類によって、配置するドライブ(ディスク)をわけてディスクI/Oを分散しましょう。
▪ 細かく分けられると理想的ですが、以下の4種類にまずはわけるとよいでしょう。
▪ 上述の空き領域のサイジングは、それぞれのドライブで30%を確保するように計算します。
▪ 別々のドライブへのデータ ファイルとログ ファイルの配置
▪ http://technet.microsoft.com/ja-jp/library/bb402876(v=sql.110).aspx
データベースとファイルの種類 既定のパス パス変更例
システムデータベース(master,model,msdb) mdf&ldf
C:¥Program Files¥Microsoft SQL Server¥MSSQL11.[インスタンスID]¥MSSQL¥DATA
D:¥SystemDB
tempdb mdf&ldf E:¥tempdb
ユーザーデータベース mdf F:¥DATA
ユーザーデータベース ldf G:¥TLOG
データベース配置先についての参考資料
▪ SharePoint Server 2013 の容量計画
▪ http://technet.microsoft.com/ja-jp/library/ff758645(v=office.15).aspx
▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013)
▪ http://technet.microsoft.com/ja-jp/library/cc298801(v=office.15).aspx
▪ パフォーマンスと容量テストの結果および推奨事項 (SharePoint Server 2013)
▪ http://technet.microsoft.com/ja-jp/library/ff608068(v=office.15).aspx
データベースとファイルの配置先は物理的に分ける
▪ データベース、データベースファイル、トランザクションログという単位で、
▪ 配置するドライブを分けると、I/O処理が分散されて、SQL Serverの処理が
▪ 速くなるのですが、論理ドライブを分けるだけでは、意味がないのです。
▪ I/O処理はディスクへアクセスして行われる処理です。
▪ つまり、ディスクをわけないと意味がないのです。
▪ では、仮想化環境やクラウド、オンプレでも予算の関係などで、ディスクをわけることが
▪ できない場合は、論理ドライブも分ける必要がない？
▪ かというとそうでもなくて、ファイルの管理をわかりやすくするために
▪ 分けるということもありです。
▪ 物理ディスクを用意して管理できる場合は、IOPSの高い(2000以上)ディスクで、
▪ RAID5か10(オススメ)にするとよいでしょう。
▪ ※IOPSとは、ハードディスクなどの記憶装置の性能指標の一つで、ある条件の元で1秒間に読み込み・書き込みできる回数のこと。
ファイルが大きくなる傾向のデータベース
▪ データベースのサイズ傾向はtechnetで公開されていますが、幅が大きすぎるので(笑)
▪ 実際に運用されているお客様環境や弊社の開発環境を参考にした傾向を書きます。
ファイル肥大化の傾向 データベース名
データベースファイルが大きくなる Search_Service_ApplicationDBSearch_Service_Application_CrawlStoreDBWSS_Loggingコンテンツデータベース
トランザクションログファイルが大きくなる SharePoint_ConfigSharePoint_AdminContentSearch_Service_ApplicationDBSearch_Service_Application_CrawlStoreDBコンテンツデータベース
トランザクションログファイルが大きくなるのは？
▪ さきほども説明したように、トランザクションログファイルは、データベースファイルへの変更処理のログが書き込まれます。
▪ データベースの役割にもよるのですが、それにしても、トランザクションログファイルのサイズに差がでます。
▪ トランザクションログファイルのサイズは、「復旧モデル」が大きく関係しています。
▪ 復旧モデルを説明する前に、トランザクションログについても、もう1つ説明します。
▪ トランザクションログは更新処理の履歴が書き込まれていますが、ファイルを開いてログの内容を解析したりすることはできません。
▪ トランザクションログをバックアップして、データベースのバックアップとあわせて
▪ リストアすることで、トランザクションログに書き込まれている更新処理の内容を
▪ 復元することができます。
▪ トランザクションログのバックアップを使って、データベースのバックアップ時点より
▪ さらに新しい更新を復元したい場合、「復旧モデル」が重要になってきます。
復旧モデル
▪ 復旧モデルは「単純」「完全」「一括ログ」の3種類があります。
種類 説明 サイズ
単純 チェックポイントが完了するごとに、現在実行されているトランザクションを除いて、トランザクション ログを切り捨てる。これによって、トランザクション ログの使用領域を最小に抑える。バックアップでの復元はできない。
小
完全 トランザクション ログへすべての処理履歴を完全に記録する。バックアップでの復元ができる。障害発生時に障害が発生した直前までデータを復旧でき、ポイント(日時)を指定した復旧もできる。
大
一括ログ 一括操作のパフォーマンス向上のために、トランザクションログへ記録する情報を最小限に抑えてる。バックアップでの復元ができる。ただし、ログに記録される情報が少ないため、ログに情報がない一部の処理はバックアップから復元できない。
中
SHAREPOINTデータベースの復旧モデル
▪ SharePoint Serverのデータベースの復旧モデルは、単純と完全の2種類が既定で設定されています。
復旧モデル データベース名
単純 Search_Service_Application_AnalyticsReportingStoreDBSearch_Service_Application_CrawlStoreDBSearch_Service_Application_DBSearch_Service_Application_LinksStoreDBUser Profile Service Application_ProfileDBUser Profile Service Application_SocialDBUser Profile Service Application_SyncDBWSS_Logging
完全 SharePoint_AdminContentSharePoint_ConfigWSS_ContentAppMng_Service_DBBdc_Service_DBManaged Metadata ServiceSecure_Store_Service_DBStateServiceWordAutomationServices
復旧モデルの確認と変更方法
▪ データベースを右クリックして、プロパティを開き、オプションを選択します。
▪ 復旧モデルの欄を参照します。変更はプルダウンして選択し、OKをクリックします。
SHAREPOINTデータベースの復旧モデルつづき
▪ 復旧モデルが完全のデータベースは、トランザクションログファイルはあまり大きくなりません。
▪ ただし、検索データベースなどは処理が多いため、単純であってもそれなりに大きくなります。
▪ どのくらい大きくなるかは処理に依存し、事前には予測できないため、検索データベースの
トランザクションログファイルの領域のサイズは余裕をもたせるようにします。
▪ 復旧モデルが完全のデータベースは、トランザクションログファイルが大きくなります。
▪ サイジング時にデータベースファイルサイズの30％でトランザクションログファイルサイズを見積っていますが、復旧モデルが完全の場合、30％を超えて、データベースファイルの数倍になることもあります。
▪ トランザクションログファイルの肥大化を放置してディスクを使いきる、ということもしばしば起こります。
▪ しかしディスクは有限なので、空き領域がなくなることを防ぐための方法が2通りあります。
トランザクションログファイルの肥大化を防ぐ方法(1)
▪ 1つ目は、復旧モデルを単純に変更することです。
▪ これによって、トランザクションログファイルのサイズ肥大化は防ぐことができますが、
▪ トランザクションログのバックアップを使ったデータ復旧はできなくなります。
▪ 復旧モデルの変更は、バックアップを使ったデータの復旧要件を考慮して決めましょう。
▪ 数人が使う開発環境であれば、直前のデータに戻す要件はほぼなく、ディスクサイズも
▪ 少ない環境が多いですから、ファーム構築後すぐにSharePointデータベース群の
▪ 復旧モデルを単純に変更することをお薦めします。
▪ 復旧モデル (SQL Server)
▪ http://msdn.microsoft.com/ja-jp/library/ms189275(v=sql.110).aspx
▪ データベースの復旧モデルの表示または変更 (SQL Server
▪ http://msdn.microsoft.com/ja-jp/library/ms189272(v=sql.110).aspx
トランザクションログファイルの肥大化を防ぐ方法(2)
▪ 2つ目は、トランザクションログのバックアップを定期的に実行して、トランザクションログファイル内のログの切り捨てを行うことです。
▪ トランザクションログをバックアップすると、コミットされた処理のログが切り捨てられ、ログファイル内に未使用領域が増えます。
▪ 新しいログは未使用領域に書き込まれるため、ファイルの肥大化を防ぐことができます。
▪ バックアップファイルを一定期間保持しておくことで、必要なときにバックアップからのデータ復旧もできるようになります。
▪ データベースのフルバックアップを取っていればOKと思いがちですが、トランザクションログの切り捨ては、トランザクションログのバックアップのみで行われます。
▪ 復旧モデルが完全のデータベースは必ずトランザクションログのバックアップを運用に組み込みましょう。
▪ ただし、バックアップを定期的に実行する仕組みを作ることと、バックアップファイルを保持する領域の確保が必要になります。あわせてバックアップする頻度も検討してください。
▪ トランザクション ログのバックアップ (SQL Server)
▪ http://msdn.microsoft.com/ja-jp/library/ms179478(v=sql.110).aspx
▪ トランザクション ログのバックアップ
▪ http://technet.microsoft.com/ja-jp/library/ms190440(v=sql.105).aspx
ファイルサイズを確認する方法は？
▪ データベースにはデータベースファイルとトランザクションログファイルがあり、
それぞれ大きくなることを説明してきました。
▪ 大きくなっていることをどうやって確認したらよいのでしょうか？
▪ SharePointのデータベースは、サーバーの全体管理からサイズを確認することはできません。
▪ PowetShellを駆使してデータベースサイズを取得することはできるようですが(やったことない)、
データベースサイズとファイルサイズは違うので・・・。
▪ ここはシンプルにSQL Serverの管理ツールを使って確認しましょう。
▪ SQL Serverの管理ツールはSQL Server Management studioといいます。SSMSと略します。
▪ SSMSを使ってファイルサイズを確認する方法は3通りあります。
(1)データベースのプロパティを参照する
(2)レポートでディスク使用量を出力する
(3)TSQL sp_helpdbを実行して、ファイルサイズを出力する
(1)データベースのプロパティを参照する
▪ SSMSでSharePoint Serverデータベースが作られているインスタンスに接続します。
▪ ファイルサイズを確認したいデータベースの「プロパティ」を開いて、「ファイル」ページからデータベースファイルとトランザクションログファイルのサイズを参照します。
▪ この方法は1～数種類のデータベースのファイルサイズをちょっと確認したいときには
▪ 簡単でよいと思います。
(2)レポートでディスク使用量を出力する
▪ SSMSでSharePoint Serverデータベースが作られているインスタンスに接続します。
▪ ファイルサイズを確認したいデータベースを右クリックして、「レポート」「標準レポート」
▪ 「ディスク使用量」をクリックしてレポートを表示します。
▪ レポート画面を右クリックして、「エクスポート」からファイルに出力することもできます。
▪ レポートでは未使用領域の割合なども確認できます。
(3)SP_HELPDB
▪ SSMSでSharePoint Serverデータベースが作られているインスタンスに接続します。
▪ 新しいクエリを開いて「sp_helpdb [データベース名]」を入力し、クエリを実行します。
▪ データベース名で指定したデータベースのサイズとファイルサイズが表示されます。
▪ クエリ結果はファイルに出力できます。
▪ このクエリを全データベース分作ると一気にサイズを確認できます。簡単便利です。
(3)SP_HELPDB 出力結果
▪ 新しいクエリを開いて「sp_helpdb 」を入力し、クエリを実行します。
▪ インスタンス上のすべてのデータベース名とサイズ、その他情報の一覧が出力されます。
▪ この方法だとファイル毎のサイズは出力されません。
(3)SP_HELPDB [データベース名] 出力結果
▪ 新しいクエリを開いて「sp_helpdb [データベース名]」を入力します。
▪ データベース毎にクエリを作っておいて、実行します。
▪ この方法だとファイル毎のサイズが出力されます。
ファイルサイズを確認する方法 参考情報
▪ [データベースのプロパティ] ([ファイル] ページ)
▪ http://msdn.microsoft.com/ja-jp/library/ms180254(v=sql.110).aspx
▪ データベースのデータ領域とログ領域情報の表示
▪ SQL Server Management Studio (レポート表示)
▪ http://msdn.microsoft.com/ja-jp/library/ms190674(v=sql.110).aspx
▪ ヒント: T-SQL を使用してデータベース情報を確認する
▪ http://technet.microsoft.com/ja-jp/sqlserver/sql_tips10.aspx
データベースファイルサイズを小さくする方法
▪ ファイルサイズを確認してみて、大きくなりすぎてたら？
▪ そんなときもSSMSを使って、ファイルサイズを小さくしましょう。
▪ まず、ファイルサイズを確認する方法(2)レポート出力で、ファイルとサイズと未使用領域の割合を確認します。
▪ データベースファイルで未使用領域の割合が多い場合は、ファイル圧縮をします。
▪ ファイル圧縮の手順
1．データベースを右クリックして「圧縮」をクリックします。
2．ファイルの種類で「データ」を選択します。
3．他にも設定する項目があります。そこは適宜変更して「OK」をクリックします。
これで未使用領域が解放されて、データベースファイルサイズが小さくなります。
▪ 未使用領域があまりない場合は、必要なサイズになっているということなのでそのままにします。
ディスクの空きが足りないようなら追加を(検討)してください。
▪ ファイルの圧縮
▪ http://msdn.microsoft.com/ja-jp/library/ms190757(v=sql.110).aspx
トランザクションログファイルサイズを小さくする方法
▪ トランザクションログファイルの圧縮もデータベースファイルの圧縮と同じ方法で出来ますが、
復旧モデルが完全のトランザクションログの場合はもう一手間が必要です。
▪ まず、ファイルサイズを確認する方法(2)レポート出力で、ファイルとサイズと未使用領域の割合を確認します。
▪ 未使用領域の割合が多い場合は、データベースファイルと同じ手順でファイル圧縮をします。
▪ 未利用領域が少ない場合は、トランザクションログのバックアップをします。
▪ 再度、データベースのレポートを出力して、トランザクションログファイルの未使用領域が増えていることを確認します。それからファイル圧縮をします。
▪ 復旧モデルが単純の場合はバックアップ不要です(しても意味がないから)。
▪ 圧縮してもディスクの空きが足りないようなら追加を(検討)してください。
トランザクションログファイルサイズを小さくする方法
トランザクションログの未使用領域が多い(50%以上)ことを確認する
タスクからファイル圧縮を開く
ファイル圧縮
▪ ファイル圧縮の画面で「ファイルの種類」から「データ」または「ログ」を選択してから
▪ 「OK」をクリックしてファイル圧縮を実行します。
データベースのバックアップ
▪ トランザクションログファイルを圧縮する前にバックアップする、という話がでてきたついでにデータベースのバックアップについても簡単に説明します。
▪ SharePointのバックアップをする場合、なにはともあれ、コンテンツデータベースをバックアップしましょう。
▪ コンテンツデータベースはユーザーのデータが入っています。
▪ どんなに優秀なエンジニアでもユーザーが作ったデータを再作成はできないのです。
▪ 失われてから後悔しないために！バックアップは忘れずに！
▪ SharePointのバックアップ方法は数種類あります。
▪ (1)サーバーの全体管理 バックアップを使う
▪ (2)PowerShellを使う
▪ (3)SQL Server のバックアップを使う
▪ (4)SharePoint用バックアップソリューション(SCDPM、AvePoint等)を使う
▪ (5)SQL用バックアップソリューション(SCDPM、BackupExec、ARCServce等)を使う
▪ (6)ストレージ製品のバックアップソリューション(NetVault等)を使う
データベースのバックアップ
▪ データベースのバックアップは、(3)から(5)を使うとよいでしょう。
▪ (3)SQL Server のバックアップを使う
→小規模、開発環境向け
▪ (4)SharePoint用バックアップソリューション(SCDPM,AvePoint等)を使う
→小～大規模向け
▪ (5)SQL用バックアップソリューション(SCDPM、BackupExec、ARCServce等)を使う
→小～大規模向け
▪ (6)ストレージ製品のバックアップソリューション(NetVault等)を使う
▪ →中～大規模向け
バックアップ要件とリストア要件
▪ コンテンツデータベースのバックアップ！と説明しましたが、コンテンツデータベースの
▪ バックアップだけだと、SharePointファームが壊れた場合は、ファームの再構築が必要です。
▪ ファームまるごとバックアップしてリストアしたい！という要件は必ず出てきますが
▪ その場合は、(2)と(3)～(6)を組み合わせるなどの方法をとります。
▪ 仮想化環境なら、イメージまるごとバックアップしたらいいよね？というご意見も必ず
▪ 賜りますが、残念ながらこれはマイクロソフトのサポート対象外になります。
▪ 複数台で構成されているファームの場合、動作しない可能性があるからだそうです。
▪ 開発環境で1台にSQLとSharePointが同居している場合は、だいたい動きます。
▪ バックアップ要件は、リストア要件に基づいて決めます。
▪ リストア要件のポイントは主に以下の点を考慮してください。
▪ (1)何を戻したいか？(コンテンツのデータ？設定データも？ファーム全部？)
▪ (2)どのくらいの時間で復旧するか？(数時間？数日？数週間？それ以上？)
▪ (3) (1)と(2)は必須？希望？
データベース以外でのあれこれ
▪ サイジングから運用中のファイル管理まで、データベースのことをいろいろ説明してきました。
▪ これで終わりではないのです。
▪ データベース以外に、設定変更をしたほうがよい点があります。
並列処理の最大限度構成オプション
▪ 並列処理の最大限度構成オプション(max degree of parallelism、MAXDOP)は、並列プランでクエリの実行に使用するプロセッサの数を制御し、0～64の値で変更ができます。
▪ SharePoint Serverファームで動くSQL Serverは、MAXDOPを 1 に設定し、単一の SQL Server プロセスがそれぞれの要求を処理するようにします。
▪ MAXDOPを1以外にしてはいけません。使用されるクエリ計画が最適でなくなり、SharePoint Serverのパフォーマンスを低下させる場合があります。
▪ 「1に設定します」と書きましたが、SharePointファーム構築時に(勝手に)1になるので、インスタンスのプロパティから、1になっていることを確認しましょう。
▪ SharePoint Server ファーム内の SQL Server のベスト プラクティス
▪ http://technet.microsoft.com/ja-jp/library/hh292622(v=office.15).aspx
▪ max degree of parallelism サーバー構成オプションの構成
▪ http://technet.microsoft.com/ja-jp/library/ms189094
▪ SQL Server における 「並列処理の最大限度」構成オプションの推奨事項、およびガイドライン
▪ http://support.microsoft.com/kb/2806535/ja
並列処理の最大限度構成オプション
インデックス断片化の解消と統計情報の更新
▪ データベースはデータのインデックスが作られてます。このインデックスを利用することでSQLServerでの処理が速くなります。
▪ インデックスはデータの更新、特に削除によって、断片化が発生します。
▪ インデックスの断片化が起きると、そのインデックスを利用する統計情報が適切でなくなり、処理が遅くなります。
▪ インデックスの断片化が起きるとすぐに処理が遅くなるわけではないですが、断片化の割合が大きくなると遅かれ早かれ(？)遅くなります。
▪ インデックスの断片化を防ぐことはできませんが、修復することはできます。
▪ インデックスの断片化の割合によって、「再編成」か「再構築」を行います。
▪ SharePoint Server 2007 RTMまでは、インデックスの断片化の解消はSQL Serverで手動で行う必要がありました。
▪ SharePoint Server 2007 SP1以降のバージョンでは、インデックス断片化の解消は、SharePoint Health Analyzer ルールで定期的に自動で行われるはず、なのですが・・・
▪ (マイク○ソフトの人にもそう言われたし・・・)
▪ SharePoint Server 2013のSharePoint Health Analyzer ルールにそれらしいものが1つしか、見当たらないのです(汗)
インデックス断片化の解消の謎？
▪ Technetから探すと、2013では、検索データベースについてのルールが1つ見つかります。
▪ 検索 - 1 つ以上のクロール データベースに断片化されたインデックスがあります (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/ff805060(v=office.15).aspx
▪ SharePoint Server 2010ではこんなルールがありました。
▪ SharePoint で使用されているデータベースのインデックスが断片化されています
▪ http://technet.microsoft.com/ja-jp/library/ff805067(v=office.14).aspx
▪ 上のルールでは断片化の解消を実行するように書かれていますが、以下のページでは
▪ このルールによって断片化の解消処理が自動で行われると書かれています。
▪ データベースメンテナンスのHealth Analyzer ルールを実行する
▪ http://technet.microsoft.com/ja-jp/library/cc262731(v=office.14).aspx#DBMaintenanceForSPS2010_MeasureAndReduceIndexFrag
▪ ただし、一部のデータベースはこのルールが適用されないから、手動で断片化の解消を
▪ 実行するようにとも書かれています。(中途半端・・・)
インデックス断片化の解消の謎？
▪ SharePoint Server 2010 のデータベース メンテナンス
▪ http://technet.microsoft.com/ja-jp/library/cc262731(v=office.14).aspx
▪ この素敵な情報のSharePoint Server 2013版が見当たらないのですが
▪ 考え方は変わってないと思われます。
▪ というのも、データベースのレポート出力に「インデックスの物理統計」というものがあり、これを出力してみると、いろいろなデータベースでインデックスの断片化が発生していることが確認できました。
▪ なので、おそらく、SharePoint Server 2013でも、インデックス断片化の解消は、
▪ SQL Serverで定期的に実行する必要がありそうです。
SHAREPOINTのデータベースメンテナンス
▪ 「SharePoint Server 2010 のデータベース メンテナンス」によるといくつかの
▪ メンテナンスを行う必要ありそうです。
(1)データベース コンソール コマンド (DBCC) CHECKDB を使用して整合性エラーの有無を確認する
(2)インデックスの断片化を測定して抑制する
(3)データベースの断片化を抑制する
(4)データ ファイルを圧縮する
▪ これらはデータベース毎に行うのですが、たくさんあるSharePointデータベースを
ひとつひとつ手動で行っていくのは、合理的ではないですね。
▪ そこで！SQL Serverの機能を使います。
▪ メンテナンスプランの作成です。
SQL SERVERのメンテナンスプランを使う
▪ SQL Serverの機能にメンテナンスプラン(Maintenance Plan)というものがあります。
▪ さきほど挙げられていたメンテナンス処理のジョブを作成し、スケジュール実行ができるのです。
▪ メンテナンスプランの作成は、メンテナンスプランウィザードを使うと簡単です。
SQL SERVERのメンテナンスプランを使う つづき
▪ ウィザード内で、スケジュールと対象のデータベースの選択もできます。
メンテナンスタスク
データベースの整合性確認
データベースの圧縮
インデックスの再構成
インデックスの再構築
統計の更新
履歴のクリーンアップ
SQL Serverエージェントジョブの実行
データベースのバックアップ(完全)
データベースのバックアップ(差分)
データベースのバックアップ(トランザクションログ)
メンテナンスのクリーンアップタスク
SQL SERVERのメンテナンスプランを使う まだつづく
▪ インデックス断片化の解消で行われる再編成と再構築の違いについて簡単に説明します。
▪ インデックスを作り直す再構築の実行時はCPUをぐぁーっと使って、負荷が高くなります。
▪ SQL Server が Standard Editionの場合は、再構築中にオフラインになります。
▪ そのため、メンテナンスプランを実行するタイミングは、ユーザー利用の少ない時間帯にするなどの考慮をしてください。
▪ ちなみに、メンテナンスプランを毎日実行しても、断片化の割合によっては、修復や再構築は行われません。
▪ ほどほどの間隔(週1とか？)で定期的に実行するといいと思います。
▪ それから再構築は時間がかかる傾向があります。それも考慮してスケジュールを検討してください。
断片化の割合 修復方法 オンライン実行
5%以下 修復しない なし
5-30% 再編成(断片化している個所を修復する) オンライン
30%以上 再構築(インデックスを作り直す) オフラインオンライン※Enterprise
データベースメンテナンスの参考資料
▪ SharePoint Server 2010 のデータベース メンテナンス
▪ http://technet.microsoft.com/ja-jp/library/cc262731(v=office.14).aspx
▪ SQL Server 2005 のメンテナンス プラン ウィザード、および SharePoint データベースに対して管理者が実行できるタスクについての情報
https://support.microsoft.com/kb/932744
▪ メンテナンス プラン
▪ http://msdn.microsoft.com/ja-jp/library/ms187658(v=sql.110).aspx
▪ メンテナンス プラン ウィザードの使用
▪ http://msdn.microsoft.com/ja-jp/library/ms191002(v=sql.110).aspx
▪ ムッシュがこんな記事を書かれていらっしゃいました。
▪ SharePoint 2010 の Health Analyzer とデータベースのメンテナンスについて
▪ https://engineermemo.wordpress.com/2012/09/28/sharepoint-2010-%E3%81%AE-health-analyzer-%E3%81%A8%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E3%83%A1%E3%83%B3%E3%83%86%E3%83%8A%E3%83%B3%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84/
インデックス断片化と統計情報の更新の参考資料
▪ インデックスの再編成と再構築
▪ http://msdn.microsoft.com/ja-jp/library/ms189858(v=sql.110).aspx
▪ インデックス再構築と再構成の違い
▪ http://blogs.msdn.com/b/jpsql/archive/2013/03/01/10397042.aspx
▪ インデックス再構築 (REBUILD) 後のデータファイル圧縮 (SHRINK)
▪ http://blogs.msdn.com/b/jpsql/archive/2013/02/05/do-s-amp-dont-s-8-rebuild-shrink.aspx
▪ 統計の更新
▪ http://msdn.microsoft.com/ja-jp/library/hh510198(v=sql.110).aspx
▪ 統計情報の自動更新が ON の時には統計情報を手動で更新する必要はない？
▪ http://blogs.msdn.com/b/jpsql/archive/2012/04/19/on.aspx
▪ やってはいけないこと - インデックス再構築 (REBUILD) 後のインデックス統計情報更新(UPDATE STATISTICS)
▪ http://blogs.msdn.com/b/jpsql/archive/2011/08/01/do-s-amp-dont-s-9-rebuild-update-statistics.aspx
設定、メンテナンス以外にできることは？
▪ SSMSを使うことで、SharePoint Serverのデータベースについて、設定したり、
▪ メンテナンスをしたり、SQL Serverインスタンスの設定を変えて、処理を速く
▪ することができる、ということがここまでの説明でした。
▪ さて、そもそもデータベースなんだから、SharePointのデータをSSMSを使って直接見たり、
▪ 更新したりすればいいかも？！
▪ という発想が出ても不思議ではないのですが、それは、SharePoint Serverとしては
▪ サポートされない操作になります。
▪ Support for changes to the databases that are used by Office server products and by Windows SharePoint Services
▪ Office サーバー製品およびWindows SharePoint Servicesによって使われるデータベースの変更に対するサポート
▪ https://support.microsoft.com/kb/841057/en-us
▪ SharePointデータベースのデータの更新は、SharePointサイトから、もしくはAPIを使わないとダメなのです。
SQLから直接参照できるSAHREPOINTデータベース
▪ 参照については、ダメとは書いてありませんが、サポートするとも書いていないのですが
▪ TechnetのSharePoint Support teamのブログ記事で、データベースのテーブルを参照してという操作が書かれているものがあるので、たぶん大丈夫でしょう。
▪ といいつつ、参照可と明記されているデータベースがあります。
▪ それは、WSS_logging です。
▪ ログ データベースのデータを表示する (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/jj715694(v=office.15).aspx
▪ 上記のtechnetから説明抜粋(手抜き)します。
▪ 「ログ データベースは、ファーム内の各サーバーから取得される SharePoint 2013 監視情報のファーム全体のリポジトリで、さまざまな監視情報を 1 つの場所で表示およびカスタマイズするオプションが用意されています。また、このログ データベースは直接変更してレポートをカスタマイズできる唯一の SharePoint 2013 データベースです。 」
▪ WSS_Logging以外のデータベースでも、データベース内のテーブルによっては
▪ 参照が可能なものもあるようです。
▪ データベースから直接データを参照することが必要になったら、できればマイクロソフトのプレミアサポートで確認してからトライしてみてください。
SQLから直接参照できるSAHREPOINTデータベース
▪ 参照については、ダメとは書いてありませんが、サポートするとも書いていないです。
▪ SharePoint Support teamのブログ記事で、「UserInfoテーブルは参照可」という
▪ 記述があるので、おそらくたぶん大丈夫でしょう。
▪ サイト コレクションのユーザー情報へのユーザー プロファイル同期の仕組みについて (まとめ)
▪ <http://blogs.technet.com/･･･/archive/2013/11/10/3608500.aspx>
▪ といいつつ、参照可と明記されているデータベースがあります。
▪ それは、WSS_logging です。
▪ ログ データベースのデータを表示する (SharePoint 2013)
▪ http://technet.microsoft.com/ja-jp/library/jj715694(v=office.15).aspx
▪ 上記のtechnetから説明抜粋(手抜き)します。
▪ 「ログ データベースは、ファーム内の各サーバーから取得される SharePoint 2013 監視情報のファーム全体のリポジトリで、さまざまな監視情報を 1 つの場所で表示およびカスタマイズするオプションが用意されています。また、このログ データベースは直接変更してレポートをカスタマイズできる唯一の SharePoint 2013 データベースです。 」
まとめ
SQL FOR SHAREPOINTのポイントSQL ServerのCPUとメモリはできるだけマイクロソフトの推奨値以上に。推奨値以下で使って遅い場合は致し方なしです。
大規模環境では、SQL Serverを動かすサーバーを複数台にしてデータベースを分散して配置し、1台あたりの処理を小さくしましょう。中規模でも2～3台以上に分散するといいですね。小規模は1台、開発環境はSharePointと同居でも大丈夫です。
データベースを分散する基準は「役割」と「サイズ」です。「サイズ」はデータベースの合計サイズとサーバーのメモリとの兼ね合いです。コンテンツデータベースを配置するSQL Serverは中～大規模環境では2台以上になるでしょう。
トランザクションログは重要です。ディスクのサイジングと運用に大きな影響があり、バックアップ/リストア要件でも忘れてはならない要素のひとつです。
SQL Serverのシステムデータベースであるtempdbのサイズとファイル数を適切に設計/設定すると、SQL Serverのパフォーマンス向上に効果があります。
SQL FOR SHAREPOINTのポイントつづきデータベースのディスクサイズのサイジングを運用開始前に正確に見積ることは困難です。運用で無駄遣いしない努力(？)と、定期的に使用状況を確認をして、必要に応じて適切にディスク増設できるようにしておきましょう。予算がある場合は、構築時にがばっと大容量を確保しておくのも手です。
SQL Serverは運用開始後もあれこれ手をかけてあげましょう。上述のディスク使用状況の確認に加えて、データベースも定期的にメンテナンスをしましょう。バックアップはデータベースはもちろん必須、トランザクションログのバックアップも忘れずに。
SSMS(SQL Server Management Studio)を活用して、SQL Serverの状態や情報を確認しましょう。
便利なSSMSですが、データベースのデータ活用は参照までにしておきましょう。データベース内のテーブル情報はあまり公開されていないので、見たいときは自力でがんばるか、マイクロソフトの(有償)サポートを受けたほうがよいでしょう。
開発環境でSharePointとSQLを1台で動かすときは、メモリ上限設定、復旧モデルをすべて単純に変更することを忘れずに。
おわび？・チューニングのネタを期待されていたとしたらゴメンナサイ
・SQL Serverのチューニングを1～2ページで説明するのはちょっと難しいデス。
・たとえば、パフォーマンスカウンターの情報はtechnetで公開されています。
でもそれだけわかってもチューニングできないですよね。
・SQL Serverのチューニングは「これをすると劇的にパフォーマンス改善！」という
魔法の呪文がないのです。
・様々な手段でボトルネックの原因を探して、その原因の対処を実施する、
という地道な作業がSQL Serverのチューニング方法です。
・チューニングをしたいと思ったときは専門家に依頼するとよいでしょう。
・SharePoint ServerとSQL Serverのサイジングと設計を適切にして、
メンテナンスを定期的に実施してあげれば、さくさく動いてくれるはず。
・ちゃんとやってるけど、遅いんだよね・・・という場合は、もしかしたら、
SharePointとSQLに無理をさせるコンテンツ運用なのかもしれません？
コンテンツの見直しか、サイトコレクションやデータサイズの分散を検討してみてください。
SQL FOR SHAREPOINTネタはまだまだある• 今日のお題は、基本的なサイジングと設計、運用のポイントが中心でした。• バックアップ/リストアについてはさらっとしか触れていませんが、これも掘り下げると深いです。• ディスクについてはIOPSもさらっと書きましたが、仮想化環境、クラウドが主流に• なってきている現状では、気にしてもどうにもならないことなので、簡単にしました(^^;• 機能については、Reporting Serviceとの連携(Enterprise機能)など、• コンテンツ連携ネタがあります。• こういった機能については、またいつの日か。
最後に• 今回の内容も、実際の案件を設計する際に使っています。
• マイクロソフト様のレビューでOKをもらっており、大きな間違いはないハズです。
• この資料はSlideShareで公開します。(一部修正するかも)
• ご清聴、ありがとうございました。
