More Related Content Similar to SQL Server for SharePoint 2013 (20) SQL Server for SharePoint 20132. 自己紹介
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は、食べ物と愛猫達の画像がほとんどです。
たまに横浜や旅行先での風景をアップしたりします。
運動が苦手なのですが、水泳とヨガはやっています。
でもヨガだけでは痩せないから、呑み会で摂取したカロリーを
消費するために、まじめに運動しないといけない今日この頃。
(水泳は時間がとれないので休止中。)
ちなみに姉御とか蟒蛇とかよく言われるのですが、そんなことないで
す!
・・・という感じですが、よろしくお願いします。
3. 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ファームを運用する際にもしかしたら役にたつかも?
4. 本日のお題目
▪ SQL Server とは?
▪ SQL Server for SharePointの目的
▪ まずはSQL Serverのサイジング
▪ SharePoint2013のデータベース
▪ コンテンツデータベース
▪ SQL Server システムデータベース
▪ tempdb
▪ ディスクサイズ
▪ トランザクションログファイル
▪ データベースファイル
▪ 復旧モデル
▪ トランザクションログファイルの肥大化を防
ぐ
▪ ファイルサイズの確認方法
▪ ファイルサイズを小さくする
▪ データベース以外でのあれこれ
▪ SharePointのデータベースメンテナンス
▪ SQLから直接参照できるSharePointデー
タベース
▪ まとめ
5. 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
6. SQL SERVER FOR SHAREPOINTの目的
▪ 今回、SQL Server のあれこれを理解する目的は何でしょう?
▪ 1つ目はSQL Serverのサイジングや設定を適切にして、SharePoint Serverが動き始めてから、
SQL Serverが遅くならないようにすることです。
▪ 2つ目は、ディスクのエコ。
SQL Serverがたくさん使うディスクを有効に使いまわすための設定や運用について、
基本的な方法を理解します。
▪ 3つ目は、運用が始まってからSQL Serverを見守り、メンテナンスする方法です。
運用監視ツールを使って監視することがひとつの方法ですが、SQL Server が
もっているツールを使って、SQL Serverの状態を確認する方法を整理します。
▪ スペシャルテクニックや、Enterpriseな使い方については、またいつか・・・。
(というか、どなたか教えてくださいw)
8. 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
9. 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とメモリにかなり依存します。
▪ できるだけ推奨値以上にしてください。
10. 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や 他のアプリケーションも
メモリを使えるようにしましょう。
11. SQL SERVERのインスタンス数と台数を決める
▪ SQL Server 1インスタンスにすべてのデータベースを保持する場合の台数は1台です。
▪ 大規模環境でデータベースのサイズが大きくなる場合は、インスタンスを増やして
データベースを分散し、インスタンスを実行するサーバーも増やすことで
SQL Serverに無理をさせずに処理をさせます。
▪ さて、インスタンスとデータベースをどのようにわけたらよいでしょうか?
12. 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が作られます。
13. 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≦)
14. SHAREPOINT2013のデータベース
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)
22. 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機能のサービスアプリケーション
26. コンテンツデータベースのサイズの上限は?
▪ 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%未満の更新
27. コンテンツデータベースとサイトコレクションの関係
▪ ところで、コンテンツデータベースは1つ以上のサイトのデータが入っています。
▪ サイトというか、サイトコレクション単位ですね。
▪ 1つのコンテンツデータベースに1つ以上のサイトコレクションが配置されます。
▪ 1つのサイトコレクションのデータを複数のコンテンツデータベースに分散することはできません。
ということで、SharePoint ファームで、いくつのサイトコレクションを作るかということも、
コンテンツデータベースのサイジングに関係してきます。
▪ 1コンテンツデータベース=1サイトコレクションの場合は、サイトコレクションはデータベースの
サイズが上限になります。
▪ 1コンテンツデータベースに複数のサイトコレクションを配置する場合は、データベース=サイト
コレクションにならないので、クォータの設定をする場合は、サイトコレクションの数とコンテンツ
データベースの関係を考慮してサイズを決めましょう。
▪ 1コンテンツデータベース=1サイトコレクションにした場合、1インスタンスに複数のコンテンツ
データベースを配置できますが、メモリとデータベースのサイズの関係に留意してデータベース
数を決めましょう。
28. コンテンツデータベースとサイトコレクションの参考資料
▪ ソフトウェアの境界と制限 (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
29. 余談:データベースの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を複数作ったときに
は、サービスアプリケーションとデータベースの関係が名前だけで判断できなくなって困ります。
30. 余談:データベースの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に各種サービスアプリケーションのデータベース名を変更する手順が書かれてい
ます。
▪ 私もまだやったことないので、いつか試してみようと思っています。以上、余談でした。
31. SQL SERVER システムデータベース
▪ SQL Serverのデータベースはシステムデータベースとユーザーデータベースに分類されます。
▪ SharePoint Server のデータベースはユーザーデータベースに該当します。
▪ システムデータベースは、SQL Serverを構成するデータベースです。
▪ システムデータベースは4種類あります。
データベース名 説明
master SQL Server のインスタンスに対するすべてのシステム レベル情報を記録
します。ログイン、構成、およびその他のデータベースが含まれます。
model SQL Server インスタンスで作成されるすべてのデータベースのテンプ
レートとして使用され、model データベースに対する変更は、それ以降に
作成されるすべてのデータベースにも適用されます。
msdb 通知とジョブをスケジュールするために SQL Server エージェントによっ
て使用されます。
tempdb 一時オブジェクトまたは中間結果セット(すべての一時テーブル、一時スト
アド プロシージャ、その他の一時的な保管項目)を保持します。
32. TEMPDB!サイズ!
▪ TemdbはSQL Serverのパフォーマンスに重要な役割を果たします。
▪ Temdbはデータの一時的な置き場でもあり、インデックスの再構築の処理を行う場所でもあ
ります。
▪ Tempdbのサイズが大きく、I/O処理が高速なシステムは、SQL Serverの処理が速くなります。
▪ Tempdbは一時データのサイズに応じて自動拡張しますが、予め大きなサイズを用意してお
くことで自動拡張の発生を防ぐと
▪ SQLはデータ処理に専念できます。
▪ Tempdbのサイズはユーザーデータベース合計値の1~10%を目安にします。
39. データベース配置先についての参考資料
▪ 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
43. 復旧モデル
▪ 復旧モデルは「単純」「完全」「一括ログ」の3種類があります。
種類 説明 サイズ
単純 チェックポイントが完了するごとに、現在実行されている
トランザクションを除いて、トランザクション ログを切り捨てる。
これによって、トランザクション ログの使用領域を最小に抑える。
バックアップでの復元はできない。
小
完全 トランザクション ログへすべての処理履歴を完全に記録する。
バックアップでの復元ができる。
障害発生時に障害が発生した直前までデータを復旧でき、ポイント
(日時)を指定した復旧もできる。
大
一括ログ 一括操作のパフォーマンス向上のために、トランザクションログへ
記録する情報を最小限に抑えてる。
バックアップでの復元ができる。
ただし、ログに記録される情報が少ないため、ログに情報がない
一部の処理はバックアップから復元できない。
中
44. SHAREPOINTデータベースの復旧モデル
▪ SharePoint Serverのデータベースの復旧モデルは、単純と完全の2種類が既定で設定されていま
す。
復旧モデル データベース名
単純 Search_Service_Application_AnalyticsReportingStoreDB
Search_Service_Application_CrawlStoreDB
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
55. ファイルサイズを確認する方法 参考情報
▪ [データベースのプロパティ] ([ファイル] ページ)
▪ 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
56. データベースファイルサイズを小さくする方法
▪ ファイルサイズを確認してみて、大きくなりすぎてたら?
▪ そんなときもSSMSを使って、ファイルサイズを小さくしましょう。
▪ まず、ファイルサイズを確認する方法(2)レポート出力で、ファイルとサイズと未使用領域の割合
を確認します。
▪ データベースファイルで未使用領域の割合が多い場合は、ファイル圧縮をします。
▪ ファイル圧縮の手順
1.データベースを右クリックして「圧縮」をクリックします。
2.ファイルの種類で「データ」を選択します。
3.他にも設定する項目があります。そこは適宜変更して「OK」をクリックします。
これで未使用領域が解放されて、データベースファイルサイズが小さくなります。
▪ 未使用領域があまりない場合は、必要なサイズになっているということなのでそのままにします。
ディスクの空きが足りないようなら追加を(検討)してください。
▪ ファイルの圧縮
▪ http://msdn.microsoft.com/ja-jp/library/ms190757(v=sql.110).aspx
64. 並列処理の最大限度構成オプション
▪ 並列処理の最大限度構成オプション(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
67. インデックス断片化の解消の謎?
▪ 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_MeasureAndReduce
IndexFrag
▪ ただし、一部のデータベースはこのルールが適用されないから、手動で断片化の解消を
▪ 実行するようにとも書かれています。(中途半端・・・)
68. インデックス断片化の解消の謎?
▪ SharePoint Server 2010 のデータベース メンテナンス
▪ http://technet.microsoft.com/ja-jp/library/cc262731(v=office.14).aspx
▪ この素敵な情報のSharePoint Server 2013版が見当たらないのですが
▪ 考え方は変わってないと思われます。
▪ というのも、データベースのレポート出力に「インデックスの物理統計」というものがあり、
これを出力してみると、いろいろなデータベースでインデックスの断片化が発生しているこ
とが確認できました。
▪ なので、おそらく、SharePoint Server 2013でも、インデックス断片化の解消は、
▪ SQL Serverで定期的に実行する必要がありそうです。
69. SHAREPOINTのデータベースメンテナンス
▪ 「SharePoint Server 2010 のデータベース メンテナンス」によるといくつかの
▪ メンテナンスを行う必要ありそうです。
(1)データベース コンソール コマンド (DBCC) CHECKDB を使用して整合性エラーの有無を確
認する
(2)インデックスの断片化を測定して抑制する
(3)データベースの断片化を抑制する
(4)データ ファイルを圧縮する
▪ これらはデータベース毎に行うのですが、たくさんあるSharePointデータベースを
ひとつひとつ手動で行っていくのは、合理的ではないですね。
▪ そこで!SQL Serverの機能を使います。
▪ メンテナンスプランの作成です。
70. SQL SERVERのメンテナンスプランを使う
▪ SQL Serverの機能にメンテナンスプラン(Maintenance Plan)というものがあります。
▪ さきほど挙げられていたメンテナンス処理のジョブを作成し、スケジュール実行ができるの
です。
▪ メンテナンスプランの作成は、メンテナンスプランウィザードを使うと簡単です。
71. SQL SERVERのメンテナンスプランを使う つづき
▪ ウィザード内で、スケジュールと対象のデータベースの選択もできます。
メンテナンスタスク
データベースの整合性確認
データベースの圧縮
インデックスの再構成
インデックスの再構築
統計の更新
履歴のクリーンアップ
SQL Serverエージェントジョブの実行
データベースのバックアップ(完全)
データベースのバックアップ(差分)
データベースのバックアップ(トランザクションログ)
メンテナンスのクリーンアップタスク
72. SQL SERVERのメンテナンスプランを使う まだつづく
▪ インデックス断片化の解消で行われる再編成と再構築の違いについて簡単に説明します。
▪ インデックスを作り直す再構築の実行時はCPUをぐぁーっと使って、負荷が高くなります。
▪ SQL Server が Standard Editionの場合は、再構築中にオフラインになります。
▪ そのため、メンテナンスプランを実行するタイミングは、ユーザー利用の少ない時間帯にす
るなどの考慮をしてください。
▪ ちなみに、メンテナンスプランを毎日実行しても、断片化の割合によっては、修復や再構築
は行われません。
▪ ほどほどの間隔(週1とか?)で定期的に実行するといいと思います。
▪ それから再構築は時間がかかる傾向があります。それも考慮してスケジュールを検討してく
ださい。
断片化の割合 修復方法 オンライン実行
5%以下 修復しない なし
5-30% 再編成(断片化している個所を修復する) オンライン
30%以上 再構築(インデックスを作り直す) オフライン
オンライン※Enterprise
73. データベースメンテナンスの参考資料
▪ 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/
74. インデックス断片化と統計情報の更新の参考資料
▪ インデックスの再編成と再構築
▪ 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
75. 設定、メンテナンス以外にできることは?
▪ 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を使わな
いとダメなのです。
76. 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以外のデータベースでも、データベース内のテーブルによっては
▪ 参照が可能なものもあるようです。
▪ データベースから直接データを参照することが必要になったら、できればマイクロソフトの
プレミアサポートで確認してからトライしてみてください。
77. 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 データベースです。 」
79. SQL FOR SHAREPOINTのポイント
SQL ServerのCPUとメモリはできるだけマイクロソフトの推奨値以上に。
推奨値以下で使って遅い場合は致し方なしです。
大規模環境では、SQL Serverを動かすサーバーを複数台にして
データベースを分散して配置し、1台あたりの処理を小さくしましょう。
中規模でも2~3台以上に分散するといいですね。
小規模は1台、開発環境はSharePointと同居でも大丈夫です。
データベースを分散する基準は「役割」と「サイズ」です。
「サイズ」はデータベースの合計サイズとサーバーのメモリとの兼ね合いです。
コンテンツデータベースを配置するSQL Serverは中~大規模環境では
2台以上になるでしょう。
トランザクションログは重要です。
ディスクのサイジングと運用に大きな影響があり、バックアップ/リストア
要件でも忘れてはならない要素のひとつです。
SQL Serverのシステムデータベースであるtempdbのサイズとファイル数を
適切に設計/設定すると、SQL Serverのパフォーマンス向上に効果があります。
82. SQL FOR SHAREPOINTネタは
まだまだある
• 今日のお題は、基本的なサイジングと設計、運用のポイントが中心でした。
• バックアップ/リストアについてはさらっとしか触れていませんが、これも掘り下げると深いです。
• ディスクについてはIOPSもさらっと書きましたが、仮想化環境、クラウドが主流に
• なってきている現状では、気にしてもどうにもならないことなので、簡単にしました(^^;
• 機能については、Reporting Serviceとの連携(Enterprise機能)など、
• コンテンツ連携ネタがあります。
• こういった機能については、またいつの日か。