SQL Server for SharePoint 2013

SQL SERVER FOR
SHAREPOINT指南
December 13th 2014
Mayumi 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)

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(100G
B≦)
Machine Translation Services
database
SharePoint Translation Services_<GUID> Small(≧1GB)
※technetではSharePoint_Loggingと書かれていますが、実際はWSS_Loggingが作られます。

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≦)

SEARCH SERVICE APPLICATION
Search Administration Search_Service_Application_DB_<GUID> Medium
(100GB≦)
Analytics Reporting Search_Service_Application_AnalyticsReportingS
toreDB_<GUID>
Medium to large
(100GB≦1TB)
Crawl Search_Service_Application_CrawlStoreDB_<GU
ID>
Medium
(100GB≦)
Link Search_Service_Application_LinkStoreDB_<GUI
D>
Medium to large
(100GB≦1TB)

コンテンツデータベース
Content database WSS_Content 200GB-
4TB
Content database
(個人用サイト)
WSS_Content_Personal 200GB-
4TB

サービスアプリケーション(ENTERPRISE機能)
Project Server ProjectWebApp Small to
Medium
(1GB≦100G
B)
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

▪ 1インスタンスあたりのデータベース最大サイズが4TB以内になりました。メモリ64GBでOK！
▪ メモリ32GBの上限値である2TB以内にするためには、(3)(4)のデータベースをさらに分散させ
ましょう。
▪ という設計をすると、最低でもインスタンスが5つ、サーバーが5台になっちゃいますね。
▪ ちなみに実際に運用してみると、サービスアプリケーションのデータベースが最大サイズまでい
くことはなかなかありません。
▪ もうすこし、インスタンス(とサーバー)を集約してみましょう。
▪ (5)Enterprise機能を使わないことが多く、その場合は(1)～(4)のデータベースだけになります。
▪ 大規模環境でコンテンツと個人用サイトのサイズがそれなりになる場合は、(1)～(4)を
4インスタンスにわけて配置します。
▪ 小規模(ユーザー数1,000以下)から中規模(ユーザー数10,000以下)の場合は
さらに集約できそうです。

コンテンツはそれなりのサイズになるけど、個人用サイトは使わない場合
＋User Profile サービスアプリケーション数GB～
(2)Search サービスアプリケーション数GB～
▪ ユーザー数が少なく、個人用サイトを使わない(ソーシャル機能が使えない)場合は、
User Profile サービスアプリケーションのデータベースのサイズはあまり大きくなりません。
▪ なので、構成とサービスアプリケーションのデータベースとまとめて1インスタンスにします。
▪ コンテンツがそれなりのサイズになる環境は、コンテンツデータベースも大きくなりますが
検索データベースのサイズもそれなりに大きく、I/Oも高くなることが予想されるため
可能であれば専用のインスタンスにします。

コンテンツのサイズが未知数、個人用サイトは使わない場合
＋User Profile サービスアプリケーション
＋Search サービスアプリケーション数GB～
▪ コンテンツのサイズが未知数の場合は、思い切って検索データベースもスとまとめて
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万
個人用サイトなし
コンテンツサイズ大
1 2 3 なし
中規模 1,000～
1万
個人用サイトなし
コンテンツサイズ大
1 2 なし
小規模～1,000 個人用サイトあり
Enterprsei機能あり
1 2 1
小規模～1,000 個人用サイトなし
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,000
10,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_65618f8e321a43bcac535166aedb2fa
8
▪ というような長～い覚えられない名前になってしまいます。
▪ 覚えられないだけでなくストアドプロシージャでデータベース名を取得するときにエラーになった
ります(困)。
▪ SQL管理者も困りますが、Search ServiceやMetadata Serviceを複数作ったときに
は、サービスアプリケーションとデータベースの関係が名前だけで判断できなくなって困ります。

余談：データベースのGUIDははずせるつづき
▪ SharePoint Server 2010から、データベース名にGUIDがつくようになり、
▪ PowerShellを使ってサービスアプリケーションを構成すればGUIDなしの
▪ データベースを作れました。
▪ でも構成ウィザードで構成するほうが楽なんですよね(^^;
▪ SharePoint Server 2013では、構成後にデータベース名からGUIDをとる方法が
▪ 公開されてました！
▪ サービスアプリケーションデータベースの名前を変更する (SharePoint 2013)
▪ この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 に使用するディスク領域の計画
tempdb のディスク領域の不足に関するトラブルシューティング

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 の容量計画
▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013)
▪ パフォーマンスと容量テストの結果および推奨事項 (SharePoint Server 2013)

データベースとファイルの配置先は物理的に分ける
▪ データベース、データベースファイル、トランザクションログという単位で、
▪ 配置するドライブを分けると、I/O処理が分散されて、SQL Serverの処理が
▪ 速くなるのですが、論理ドライブを分けるだけでは、意味がないのです。
▪ I/O処理はディスクへアクセスして行われる処理です。
▪ つまり、ディスクをわけないと意味がないのです。
▪ では、仮想化環境やクラウド、オンプレでも予算の関係などで、ディスクをわけることが
▪ できない場合は、論理ドライブも分ける必要がない？
▪ かというとそうでもなくて、ファイルの管理をわかりやすくするために
▪ 分けるということもありです。
▪ 物理ディスクを用意して管理できる場合は、IOPSの高い(2000以上)ディスクで、
▪ RAID5か10(オススメ)にするとよいでしょう。
▪ ※IOPSとは、ハードディスクなどの記憶装置の性能指標の一つで、ある条件の元で1秒間に読み
込み・書き込みできる回数のこと。

ファイルが大きくなる傾向のデータベース
▪ データベースのサイズ傾向はtechnetで公開されていますが、幅が大きすぎるので(笑)
▪ 実際に運用されているお客様環境や弊社の開発環境を参考にした傾向を書きます。
ファイル肥大化の傾向データベース名
データベースファイルが大きくなる Search_Service_ApplicationDB
Search_Service_Application_CrawlStoreDB
WSS_Logging
トランザクションログファイルが大きくなる SharePoint_Config
SharePoint_AdminContent
Search_Service_ApplicationDB

トランザクションログファイルが大きくなるのは？
▪ さきほども説明したように、トランザクションログファイルは、データベースファイルへの変更
処理のログが書き込まれます。
▪ データベースの役割にもよるのですが、それにしても、トランザクションログファイルのサイズ
に差がでます。
▪ トランザクションログファイルのサイズは、「復旧モデル」が大きく関係しています。
▪ 復旧モデルを説明する前に、トランザクションログについても、もう1つ説明します。
▪ トランザクションログは更新処理の履歴が書き込まれていますが、ファイルを開いてログの内容
を解析したりすることはできません。
▪ トランザクションログをバックアップして、データベースのバックアップとあわせて
▪ リストアすることで、トランザクションログに書き込まれている更新処理の内容を
▪ 復元することができます。
▪ トランザクションログのバックアップを使って、データベースのバックアップ時点より
▪ さらに新しい更新を復元したい場合、「復旧モデル」が重要になってきます。

復旧モデル
▪ 復旧モデルは「単純」「完全」「一括ログ」の3種類があります。
種類説明サイズ
単純チェックポイントが完了するごとに、現在実行されている
トランザクションを除いて、トランザクションログを切り捨てる。
これによって、トランザクションログの使用領域を最小に抑える。
バックアップでの復元はできない。
小
完全トランザクションログへすべての処理履歴を完全に記録する。
バックアップでの復元ができる。
障害発生時に障害が発生した直前までデータを復旧でき、ポイント
(日時)を指定した復旧もできる。
大
一括ログ一括操作のパフォーマンス向上のために、トランザクションログへ
記録する情報を最小限に抑えてる。
バックアップでの復元ができる。
ただし、ログに記録される情報が少ないため、ログに情報がない
一部の処理はバックアップから復元できない。
中

SHAREPOINTデータベースの復旧モデル
▪ SharePoint Serverのデータベースの復旧モデルは、単純と完全の2種類が既定で設定されていま
す。
復旧モデルデータベース名
単純 Search_Service_Application_AnalyticsReportingStoreDB
Search_Service_Application_DB
Search_Service_Application_LinksStoreDB
User Profile Service Application_ProfileDB
User Profile Service Application_SocialDB
User Profile Service Application_SyncDB
WSS_Logging
完全 SharePoint_AdminContent
SharePoint_Config
WSS_Content
AppMng_Service_DB
Bdc_Service_DB
Managed Metadata Service
Secure_Store_Service_DB
StateService
WordAutomationServices

復旧モデルの確認と変更方法
▪ データベースを右クリックして、プロパティを開き、オプションを選択します。
▪ 復旧モデルの欄を参照します。変更はプルダウンして選択し、OKをクリックします。

SHAREPOINTデータベースの復旧モデルつづき
▪ 復旧モデルが完全のデータベースは、トランザクションログファイルはあまり大きくなりません。
▪ ただし、検索データベースなどは処理が多いため、単純であってもそれなりに大きくなります。
▪ どのくらい大きくなるかは処理に依存し、事前には予測できないため、検索データベースの
トランザクションログファイルの領域のサイズは余裕をもたせるようにします。
▪ 復旧モデルが完全のデータベースは、トランザクションログファイルが大きくなります。
▪ サイジング時にデータベースファイルサイズの30％でトランザクションログファイルサイズを見
積っていますが、復旧モデルが完全の場合、30％を超えて、データベースファイルの数倍になる
こともあります。
▪ トランザクションログファイルの肥大化を放置してディスクを使いきる、ということもしばしば
起こります。
▪ しかしディスクは有限なので、空き領域がなくなることを防ぐための方法が2通りあります。

トランザクションログファイルの肥大化を防ぐ方法(1)
▪ 1つ目は、復旧モデルを単純に変更することです。
▪ これによって、トランザクションログファイルのサイズ肥大化は防ぐことができますが、
▪ トランザクションログのバックアップを使ったデータ復旧はできなくなります。
▪ 復旧モデルの変更は、バックアップを使ったデータの復旧要件を考慮して決めましょう。
▪ 数人が使う開発環境であれば、直前のデータに戻す要件はほぼなく、ディスクサイズも
▪ 少ない環境が多いですから、ファーム構築後すぐにSharePointデータベース群の
▪ 復旧モデルを単純に変更することをお薦めします。
▪ 復旧モデル (SQL Server)
▪ http://msdn.microsoft.com/ja-jp/library/ms189275(v=sql.110).aspx
▪ データベースの復旧モデルの表示または変更 (SQL Server

トランザクションログファイルの肥大化を防ぐ方法(2)
▪ 2つ目は、トランザクションログのバックアップを定期的に実行して、トランザクションログファイル内
のログの切り捨てを行うことです。
▪ トランザクションログをバックアップすると、コミットされた処理のログが切り捨てられ、ログファイル
内に未使用領域が増えます。
▪ 新しいログは未使用領域に書き込まれるため、ファイルの肥大化を防ぐことができます。
▪ バックアップファイルを一定期間保持しておくことで、必要なときにバックアップからのデータ復旧もで
きるようになります。
▪ データベースのフルバックアップを取っていればOKと思いがちですが、トランザクションログの切り捨て
は、トランザクションログのバックアップのみで行われます。
▪ 復旧モデルが完全のデータベースは必ずトランザクションログのバックアップを運用に組み込みましょう。
▪ ただし、バックアップを定期的に実行する仕組みを作ることと、バックアップファイルを保持する領域の
確保が必要になります。あわせてバックアップする頻度も検討してください。
▪ トランザクションログのバックアップ (SQL Server)
▪ トランザクションログのバックアップ
▪ 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)レポートでディスク使用量を出力する
▪ ファイルサイズを確認したいデータベースを右クリックして、「レポート」「標準レポート」
▪ 「ディスク使用量」をクリックしてレポートを表示します。
▪ レポート画面を右クリックして、「エクスポート」からファイルに出力することもできます。
▪ レポートでは未使用領域の割合なども確認できます。

(3)SP_HELPDB
▪ 新しいクエリを開いて「sp_helpdb [データベース名]」を入力し、クエリを実行します。
▪ データベース名で指定したデータベースのサイズとファイルサイズが表示されます。
▪ クエリ結果はファイルに出力できます。
▪ このクエリを全データベース分作ると一気にサイズを確認できます。簡単便利です。

(3)SP_HELPDB 出力結果
▪ 新しいクエリを開いて「sp_helpdb 」を入力し、クエリを実行します。
▪ インスタンス上のすべてのデータベース名とサイズ、その他情報の一覧が出力されます。
▪ この方法だとファイル毎のサイズは出力されません。

(3)SP_HELPDB [データベース名] 出力結果
▪ 新しいクエリを開いて「sp_helpdb [データベース名]」を入力します。
▪ データベース毎にクエリを作っておいて、実行します。
▪ この方法だとファイル毎のサイズが出力されます。

ファイルサイズを確認する方法参考情報
▪ [データベースのプロパティ] ([ファイル] ページ)
▪ データベースのデータ領域とログ領域情報の表示
▪ SQL Server Management Studio (レポート表示)
▪ ヒント: T-SQL を使用してデータベース情報を確認する
▪ http://technet.microsoft.com/ja-jp/sqlserver/sql_tips10.aspx

データベースファイルサイズを小さくする方法
▪ ファイルサイズを確認してみて、大きくなりすぎてたら？
▪ そんなときもSSMSを使って、ファイルサイズを小さくしましょう。
▪ まず、ファイルサイズを確認する方法(2)レポート出力で、ファイルとサイズと未使用領域の割合
を確認します。
▪ データベースファイルで未使用領域の割合が多い場合は、ファイル圧縮をします。
▪ ファイル圧縮の手順
1．データベースを右クリックして「圧縮」をクリックします。
2．ファイルの種類で「データ」を選択します。
3．他にも設定する項目があります。そこは適宜変更して「OK」をクリックします。
これで未使用領域が解放されて、データベースファイルサイズが小さくなります。
▪ 未使用領域があまりない場合は、必要なサイズになっているということなのでそのままにします。
ディスクの空きが足りないようなら追加を(検討)してください。
▪ ファイルの圧縮

トランザクションログファイルサイズを小さくする方法
▪ トランザクションログファイルの圧縮もデータベースファイルの圧縮と同じ方法で出来ますが、
復旧モデルが完全のトランザクションログの場合はもう一手間が必要です。
▪ まず、ファイルサイズを確認する方法(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

並列処理の最大限度構成オプション

インデックス断片化の解消と統計情報の更新
▪ データベースはデータのインデックスが作られてます。このインデックスを利用することでSQL
Serverでの処理が速くなります。
▪ インデックスはデータの更新、特に削除によって、断片化が発生します。
▪ インデックスの断片化が起きると、そのインデックスを利用する統計情報が適切でなくなり、処
理が遅くなります。
▪ インデックスの断片化が起きるとすぐに処理が遅くなるわけではないですが、断片化の割合が大
きくなると遅かれ早かれ(？)遅くなります。
▪ インデックスの断片化を防ぐことはできませんが、修復することはできます。
▪ インデックスの断片化の割合によって、「再編成」か「再構築」を行います。
▪ 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)
▪ SharePoint Server 2010ではこんなルールがありました。
▪ SharePoint で使用されているデータベースのインデックスが断片化されています
▪ 上のルールでは断片化の解消を実行するように書かれていますが、以下のページでは
▪ このルールによって断片化の解消処理が自動で行われると書かれています。
▪ データベースメンテナンスのHealth Analyzer ルールを実行する
▪ http://technet.microsoft.com/ja-
jp/library/cc262731(v=office.14).aspx#DBMaintenanceForSPS2010_MeasureAndReduce
IndexFrag
▪ ただし、一部のデータベースはこのルールが適用されないから、手動で断片化の解消を
▪ 実行するようにとも書かれています。(中途半端・・・)

インデックス断片化の解消の謎？
▪ SharePoint Server 2010 のデータベースメンテナンス
▪ この素敵な情報の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 のデータベースメンテナンス
▪ SQL Server 2005 のメンテナンスプランウィザード、および SharePoint データベースに
対して管理者が実行できるタスクについての情報
https://support.microsoft.com/kb/932744
▪ メンテナンスプラン
▪ メンテナンスプランウィザードの使用
▪ ムッシュがこんな記事を書かれていらっしゃいました。
▪ 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://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で公開します。(一部修正するかも)
• ご清聴、ありがとうございました。

SQL Server for SharePoint 2013

More Related Content

SQL Server for SharePoint 2013