[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)

50分で理解する
SQL Serverでできることできないこと

株式会社インサイトテクノロジー
テクノロジーソリューション部
内山義夫

Copyright © 2011 Insight Technology, Inc. All Rights Reserved. 1

Agenda

• １．SQL Serverってどうなの？
• ２．SQL Serverでできることできないこと
– 2-1.ロックの仕様の違いを理解する
– 2-2.オブジェクトの仕様の違いを理解する
– 2-3.パフォーマンス管理ツールを理解する
• ３．まとめ


1. SQL Serverってどうなの?
Serverってどうなの?


SQL Serverのイメージ

• SQL Serverといえば・・・？

出荷本数シェァNo.1 GUIによる高いユーザビリティ

洗練されたBI機能オールインワンによる低コスト


現場の本音

これからOracle以外の
これから Oracle以外で提案すると
Oracle
DBを覚えるのが大変失敗した時に「何でOracleに
失敗した時に「何で
しなかった」と言われそう
ロック待ちが多発
SQL Server
Serverができる⼈
するんじゃない？
って誰かいたっけ？

チューニングって
できないんでしょ？

この前導入した案件は
うまくいかなかった
らしい・・・
•アプリケーション開発者 •お客様に提案する⽴場の⼈


データベースの現実

• データベースのデファクトスタンダードは間違いなくOracle
• ただし、一昔前のように何でもOracle、というわけではなく
なってきつつある
⇒適材適所にデータベースを配置
• トップダウンでデータベースが決まるケースも・・・
⇒Oracleしか知らないでは済まされなくなってきている
• ひとつのデータベース技術だけでは生き残れない
• SQL Serverも⻤熱い（弊社⼩幡談）

DBでできることできないことを正しく理解することが重要！


2.SQL Serverでできることできないこと
Serverで


SQL Serverでできることできないこと

• 理解すべきポイント
設計フェーズ開発フェーズ運用フェーズ

•ロックの仕様の •オブジェクトの •パフォーマンス
違いを理解する仕様の違いを管理ツールを
理解する理解する

フェーズが後になればなるほど手戻りも増大！


2-1.ロックの仕様の違いを理解する
1.ロックの仕様の違いを理解する


設計フェーズ

ロックの仕様の違いを理解する開発フェーズ
運用フェーズ
運用フェーズ

ロックの仕様の違いを理解するポイント

•トランザクション分離レベル

•ロックエスカレーション


設計フェーズ

運用フェーズ
運用フェーズ

• トランザクション分離レベル
– 同時に複数のトランザクションが実⾏した時の影響を定義
– Oracle、SQL Server共にread committed
– Read Committed…コミットしたデータが読める隔離レベル
Read Committed
Oracle
マルチバージョニング⽅式（オプティミスティック同時実⾏制御）
- 対象となるリソースに対して排他ロックを取得
- 排他ロック取得中でも更新前コミット済みデータが⾒れる
- 更新前データはUndo Segmentに保持

SQL Server
ロック⽅式（ペシミスティック同時実⾏制御）
- 対象となるリソースに対して排他ロックを取得
- 排他ロック取得中は他の処理を待機させる


設計フェーズ

OracleとSQL Serverの動き方開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Oracle SQL Server
マルチバージョニング⽅式ロック⽅式

トランザクションA開始トランザクションA開始
トランザクションB開始トランザクションB開始
UserA：400 UserA：400
UserB：200 UserB：200
Update 売上 Update 売上
Set 売上 = 売上 + 100 Set 売上 = 売上 + 100
Where ID = ‘UserA’; Where ID = ‘UserA’;
Select * From 売上; Select * From 売上;

UserA：500 トランザクションAが
ロック待ち
UserB：200 更新する前の値を参照
UserA：400
Commit; Commit;
UserB：200

Commit; Commit;
ロック待ち解放
UserA：500
UserB：200


設計フェーズ

トランザクション分離レベルの変更開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• Oracleの仕様を前提に開発する場合、SQL Serverのトランザ
クション分離レベルをRead Committed Snapshotに変更する
SQL Server
Read Committed
Oracle
Read Committed ≒ Read Committed Snapshot


設計フェーズ

Read Committed Snapshot時の動き開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Select⽂実⾏時

トランザクションA開始
トランザクションB開始
UserA：400 インデックスの
UserB：200
Update 売上有無は関係無
Set 売上 = 売上 + 100
Where ID = ‘UserA’;
UserA：500
UserB：200
Select * From 売上;
更新前データは
tempDBに保持トランザクションAが
更新する前の値を参照
UserA：400
Commit;
UserB：200
Commit;


設計フェーズ

SQl ServerのRead Committed 開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• 気を付けるべきポイント
– Update文やDelete文の実⾏には注意が必要！
⇒インデックスの有無で動きが大きく異なる


設計フェーズ

OracleとSQL Serverの動き方開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

トランザクションA開始
トランザクションB開始
UserA：400
UsarB：200
Update 売上
Set 売上 = 売上 + 100
Where ID = ‘UserA’;
Select * From 売上;

IDにインデックス有 IDにインデックス無

トランザクションAがロック待ち発生！
更新する前の値を参照
Commit; Commit;
UserA：400
UserB：200
ロック待ち解放


設計フェーズ

SQL Serverのロック開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• SQL Serverではロックを考慮した設計した設計が必要
– ⾏を大量にロックするような処理はなるべく控える
– アプリケーションはできるだけショートトランザクションにする
– Update文やDelete文で指定する条件の項目にはインデックスは必須
– ロック待ちやデッドックの情報を取得しておく


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• ロックエスカレーション（SQL Serverのみ）
– 粒度の⼩さいロックを変換し粒度が大きいロックにする動き
– ロックエスカレーションが発生する条件
• メモリリソースのしきい値
– SQL Serverが使用するメモリの40%を超えた場合
• ロック数のしきい値
– 1SQLステートメントで5000以上のロックを取得する場合

– ロックエスカレーションを使用しないようにするには・・・
• Trace flag 1211で制御
• ※テーブル単位の場合
alter table [テーブル名] set ( LOCK_ESCALATION = DISABLE );


設計フェーズ

Oracleのようにした場合・・・開発フェーズ
運用フェーズ
運用フェーズ

トランザクション分離レベルロックエスカレーション
Read Committed
Trace flag 1211に設定
Read Committed Snapshot （ロックエスカレーションOFF）

オーバーヘッドはどうなるか？


設計フェーズ

オーバーヘッド開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• Read Committed Snapshotのオーバーヘッド
50 100 150
TPS

142 100%
Read Committed
100%
TPS

128 90% I/O req/sec@tempdb
Read Committed Snapshot
30 30,000%

I/O req/sec

30 @tempdb
10 20

• ロックエスカレーションさせない場合のリソースの変化
50 100 150
TPS

Read Committed 69 100%

with Lock Escalation 171 100%
TPS

136 198% Memory Size@Lock
Read Committed
With trace flag 1211 184 108%

Memory Size(MB)

100 150 200 @Lock


2-2.オブジェクトの仕様の違いを理解する
2.オブジェクトの仕様の違いを理解する


設計フェーズ

オブジェクトの仕様の違いを理解する開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

オブジェクトの仕様を理解するポイント

シーケンス

パーティション

マテリアライズドビュー

PL/SQL


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ


シーケンス



PL/SQL


設計フェーズ

SQL Server de シーケンス開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Sequence
・連続した数値を采番するオブジェクト
・複数のセッションからでもユニークな値を采番可能
・SQL Serverにはオブジェクトとして采番するものは存在しない
⇒采番する機能としてはIdentity属性が該当

Oracle：シーケンス SQL Server：Identity

・値を自動的に采番・○値を自動的に采番
・オブジェクトとして作成・×オブジェクトとして作成
・特定のカラムに依存しないで采番可能・×特定のカラムに依存しないで采番可能
・増分値や開始値が設定可能・○増分値や開始値が設定可能
・最大値が設定可能・△最大値はデータ型の最大値固定
・⽂字列のカラムにも指定可能・○⽂字列のカラムにも指定可能
・カラム属性として定義可能・○カラムの属性として定義可能
・※１つのテーブルに１つのみ作成可能


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• SQL Serverでシーケンスを理解するポイント：
⇒SQL ServerのIdentityでOracleのシーケンスのような動
きがどこまでできるのか？


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

Oracle：シーケンス SQL Server：Identity

■シーケンス作成
CREATE SEQUENCE seq_1
START WITH 1
INCREMENT BY 1
MAXVALUE 1
MINVALUE 10000;

※テーブルの属性として定義する場合 ※テーブルの属性として定義する場合
CREATE TABLE table1 CREATE TABLE table1
(col1 NUMBER DEFAULT seq_1.NEXTVAL (col1 int IDENTITY(1,1),
col2 NUMBER); col2 int);

■番号取得⇒更新 ■番号取得⇒更新
DECLARE v_seq NUMBER; INSERT INTO table1 (col2)
SELECT seq_1.NEXTVAL INTO v_seq FROM DUAL; OUTPUT inserted.col1
VALUES(100) ;
INSERT INTO table1
VALUES (v_seq,100);


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• ちなみに・・・
• SQL Server次期バージョンリリース

ポイント
シーケンスオブジェクトが追加


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

Oracle：シーケンス SQL Server：シーケンス

・値を自動的に采番・○値を自動的に采番
・オブジェクトとして作成・○オブジェクトとして作成
・特定のカラムに依存しないで采番可能・○特定のカラムに依存しないで采番可能
・増分値や開始値が設定可能・○増分値や開始値が設定可能
・最大値が設定可能・○最大値が設定可能
・⽂字列のカラムにも指定可能・○⽂字列のカラムにも指定可能
・カラム属性として定義可能・○カラム属性として定義可能


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

Oracle：シーケンス SQL Server：シーケンス

■シーケンス作成 ■シーケンス作成
CREATE SEQUENCE seq_1 CREATE SEQUENCE seq_1 AS INT
START WITH 1 MINVALUE 1
INCREMENT BY 1 MAXVALUE 100000
MAXVALUE 1 START WITH 1
MINVALUE 10000; INCREMENT BY 1;

※テーブルの属性として定義する場合 ※テーブルの属性として定義する場合
CREATE TABLE table1 CREATE TABLE table1
(col1 NUMBER DEFAULT seq_1.NEXTVAL (col1 NUMBER DEFAULT NEXT VALUE
col2 NUMBER); col2 NUMBER);

■番号取得⇒更新 ■番号取得⇒更新
DECLARE v_seq NUMBER;
SELECT seq_1.NEXTVAL INTO v_seq FROM DUAL; DECLARE @v_seq INT = NEXT VALUE FOR seq_1;

INSERT INTO table1 VALUES (v_seq,100); INSERT INTO table1 VALUES (@v_seq,100);


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ


シーケンス



PL/SQL


設計フェーズ

SQL Server de パーティション開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Partitioning
・1 つのテーブルを一定の基準で分割する
- 複数パーティションに格納されたデータをパラレルに抽出可能
- データ抽出範囲（障害範囲）の極⼩化
・アプリケーションから透過的

Oracle：パーティション SQL Server：パーティション

・パーティションによる負荷分散・○パーティションによる負荷分散
・パーティション可能なオブジェクト・○パーティション可能なオブジェクト
-テーブル、インデックス -テーブル、インデックス
・パーティション⽅式を選択可能・×パーティション⽅式を選択可能
-レンジ/リスト/ハッシュ △ -レンジ/リスト/ハッシュ
・パーティション毎にバックアップが可能・○パーティション毎にバックアップが可能
・障害範囲の極小化・○障害範囲の極小化


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• パーティションの種類
SQL Server
レンジパーティションでも使用可能リストパーティションハッシュパーティション
売上テーブル売上テーブル売上テーブル
date tokid Id

2008 TOKA 1

2008 2008年 TOKA 得意先A 103 Hash key 1
2008 TOKA 177

date tokid

2009 TOKB 2

2009 2009年 TOKB 得意先B 333 Hash key 2
2009 TOKB 457

date Tokid

2010 TOKC 8

2010 2010年 TOKC 得意先C 128 Hash key 3
2010 TOKC 134

date tokid

2011 TOKD 9

2011 2011年 TOKZ その他 113 Hash key 4
2011 TOKN 198


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• パーティションのポイント：
⇒パーティションのパフォーマンスは？


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• SQL Serverパーティション
– パーティションによる負荷分散

非partitioned partitioned ・1,000,000件データ
table table
・select count(*)

・非Partitioned table
… 7.8GB 8分14秒
Physical Physical Physical ・・・
Table Partition Partition ・Partitioned table
… 7.8GB 4分03秒


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• ちなみに・・・
– SQL Serverのデータ圧縮と組み合わせることで高速化可能
•パーティション分割のみ •パーティション分割＋データ圧縮
・1,000,000件データ・1,000,000件データ
・select count(*) ・select count(*)

・非Partitioned table ・非Compression table
… 7.8GB 8分14秒 … 7.8GB 8分14秒
・Partitioned table ・Compression table
… 7.8GB 4分03秒 … 20.8MB 1.3秒
シーケンスだけ
異なるほぼ同じデータを
ページ単位で圧縮


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ


シーケンス



PL/SQL


設計フェーズ

SQL Server de マテビュー開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Materialized View
・実体のあるビューのこと
・マテビューへの更新タイミングは任意に指定可能
・DBリンクと組み合わせることで、テーブルレプリケーションも可能
・SQL Serverではインデックス付きビューが最も近い機能

Oracle：マテリアライズドビュー SQL Server：インデックス付きビュー

・マテビューへデータを反映する・×マテビューへデータを反映する
タイミングは任意に指定可能タイミングは任意に指定可能
- 完全リフレッシュ × - 完全リフレッシュ
- 高速リフレッシュ（On Demand） × - 高速リフレッシュ（On Demand）
- 高速リフレッシュ（On Commit） × - 高速リフレッシュ（On Commit）
・クエリーリライト機能（クエリを自動・○クエリーリライト機能（クエリを自動
で書き換え）で書き換え）
・DBリンクと組み合わせてテーブル単位・× DBリンクと組み合わせてテーブル単位
のレプリケーションのレプリケーション


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• インデックス付きビュー
– 通常のビューを作成し、そのビューにインデックスを作成
– 作成するインデックスはクラスタインデックスのみ
• クラスタインデックス≒Oracleの索引構成表

– インデックス付きビュー作成例
– 基テーブル
Sales.SalesOrderHeader （ AdventureWorks DBを使用）

– ビューの作成
CREATE VIEW v_SalesOrderCount WITH SCHEMABINDING AS
SELECT SOH.CustomerID, COUNT_BIG(*) order_cnt
FROM Sales.SalesOrderHeader SOH
GROUP BY SOH.CustomerID;

– インデックス付きビューの作成
CREATE UNIQUE CLUSTERED INDEX v_SalesOrderCount_idx
ON v_SalesOrderCount(CustomerID)


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• SQL Server de マテビューのポイント：
⇒制約の多さ＋パフォーマンス


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ

• インデックス付きビューの懸念点
– インデックス付きビューの制約
• インデックス付きビュー内で他のビューは参照不可
• 外部結合または⾃⼰結合は不可
• ORDER BY句は不可
• UNION、EXCEPT、INTERSECT句は不可
• DISTINCTオプションは不可
• AVG、MAX、MIN、STDEV、STDEVP、VAR、または VARP 集計関数は不可
• ⇒ただし、SUM関数やCOUNT_BIG関数と一緒に使うことは可能

– パフォーマンス懸念点
• 基テーブル更新時のオーバーヘッド
• トランザクションの同時実⾏性


設計フェーズ

開発フェーズ
運用フェーズ
運用フェーズ


シーケンス



PL/SQL


設計フェーズ

4.SQL Server de PL/SQL（拡張SQL）開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

PL/SQL（拡張SQL）
・SQLを拡張して手続き型言語として作成可能
・業務ロジックをデータベースに実装可能
・プロシージャやファンクション、トリガー等をストアドとして定義
・SQL ServerではTransact-SQLが該当

Oracle：PL/SQL SQL Server：Transact-SQL

・パッケージ、プロシージャ、・△パッケージ、プロシージャ、
ファンクション、トリガーファンクション、トリガー
・変数、定数、CURSORの定義・○変数、定数、 CURSORの定義
・FOR LOOP、WHILE、IF⽂の使用・○FOR LOOP、WHILE、IF⽂の使用
・動的SQLの使用・○動的SQLの使用
・エラーハンドリング・○エラーハンドリング
・ストアドとして定義・○ストアドとして定義


設計フェーズ

SQL Server Migration Assistantとは開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• PL/SQLをより詳細に比較する為に・・・
– ツールを使用してPL/SQLを比較
• SQL Server Migration Assistant for Oracle（SSMA）

• SQL Server Migration Assistant for Oracle（SSMA）
– データベースのマイグレーションを分析、評価、支援するツール
– スキーマのマイグレーション
– PL/SQLをTransact-SQLにマイグレーション
– 一部の関数やシーケンスは、SSMAがエミューレート
– Microsoft社から無償で提供
– 最新は5.1。最新はDenaliにも対応（らしい）


設計フェーズ

SSMAの画面開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Oracle：PL/SQL SQL Server：Transact-SQL

エラー一覧

（資料： http://blogs.msdn.com/b/ssma/archive/2010/11/30/video-creating-custom-ssma-report.aspx ）


設計フェーズ

SSMAの結果開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

SSMAによるオブジェクト変換率
オブジェクト変換率（PL/SQL以外） PL/SQL変換率
Object type Total With errors Converted Object type Total With errors Converted
index 2735 17 99% function 294 74 75%
schema 21 18 14% package 1958 1571 20%
sequence 177 0 100% packaged-function 9640 2899 70%
synonym 16 15 6% packaged-procedure 2429 1104 55%
table 7008 867 88% private-packaged-function 1239 466 62%
view 1100 269 76% private-packaged-procedure 1693 452 73%
Total 11057 1186 89% procedure 1145 586 49%
trigger 2744 1705 38%
Total 21142 8857 58%

タイプ型変換率
Object type Total With errors Converted
collection-type 6 6 0%
object-type 6 6 0%
packaged-type 2927 0 100%
private-packaged-type 561 0 100%
Total 3500 12 100%


設計フェーズ

PL/SQL変換エラーTop.8 開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

関数一覧（使用数別）

SQL文が不正 58168

関数が変換不可 13594

%type等型の変数の使用 6562

SQLCODE、SQLERRMの不正使用 4223

動的に作成されたクエリは手動変換が必要 2029

関数内ではグローバルカーソルを使用不可 1672

定義が不正な変数（%type等）の使用 979

ROWIDは使用不可 449

0 20000 40000 60000
使用数


設計フェーズ

PL/SQL変換エラーTop.8 詳細開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Package/Procedure/Function/Trigger/View
Messages Cause Workaround 件数

SQL文の不正
- SELECT句のカラム VIEWのコンパイルエラー VIEWのエラー原因を特定
- INTO句で指定した変数変数の宣言エラー（%type等）変数の定義し直し 58168
- SQLの構文が不正 SQL Serverに未対応のSQL文 SQL文の書き換え
（Merge文）

関数が変換不可
⇒別ページ参照 ⇒別ページ参照 13594
（SUBSTRB関数やDBMS_OUTPUTなど）

%type等型の変数の使用 SQL Serverに%typeや%rowtypeが存在しない変数の定義し直し 6562

EXCEPTION ブロック外でSQLCODE、SQLERRM
SQLCODE、SQLERRMの不正使用仕様の確認、構文の修正 4223
を使用

動的SQL⾃体は実⾏可
動的に作成されたクエリは手動での変換が必要変換後のSQL文を確認 2029
組み替えられたSQLは確認が必要

関数内ではグローバルカーソルを使用不可グローバルカーソル 1672

定義が不正な変数（%type等）の使用 %typeで定義された変数を計算式等で使用している変数の定義を確認 979

ROWIDは使用不可 ROWIDはSQL Serverに存在せず主キーを指定するよう変更 449


設計フェーズ

関数エラー Top.8 開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

関数一覧（使用数別）

SUBSTRB 12067

LENGTHB 530

MAX 168

UTL_FILE 166

INSTRB 128

DBMS_SQL 100

DBMS_OUTPUT 91

TO_MULTI_BYTE 85

0 5000 10000 15000
使用数


設計フェーズ

関数エラー Top.8 詳細開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Function Cause 件数
SUBSTRB SUBSTRB関数に対応する関数がない 12067
LENGTHB LENGTHB関数に対応する関数がない 530
GROUP BY句が不正
MAX GROUP BYで関数を使用 168
不正なVIEWの使用
UTL_FILE ほとんどがUTL_FILE.FCLOSE_ALLが使用不可 166
INSTRB INSTRB関数に対応する関数がない 128
DBMS_SQL ほとんどがDBMS_SQL.COLUMN_VALUEが使用不可 100
DBMS_OUTPUT DBMS_OUTPUT.DISABLE/ENABLEが使用不可 91
TO_MULTI_BYTE INSTRB関数に対応する関数がない 85


設計フェーズ

SSMAでの変換エラー Top.8 ~PL/SQL以外~ 開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

Table/Index/Synonym/Sequence
Messages Workaround LEVEL 件数
PUBLIC SYNONYMの使用スキーマ毎にSYNONYMを作成 Warning 1797
NUMBER型の桁数未指定仕様確認後桁数を定義 Warning 182
シーケンスが変換できない 2-2参照 Warning 173
一時テーブルの使用セッション単位で一時テーブルを作成 Warning 64
マテリアライズドビューの使用 2-2参照 Error 49
RANGE PARTITIONの使用 SSMAでは自動変換されない Error 41
LIST PARTITIONの使用 2-2参照 Error 30
INDEXのカラム数が多すぎ INDEXの見直し Error 30


2-3. パフォーマンス管理ツールを理解する


設計フェーズ

パフォーマンス管理ツールを理解する開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

パフォーマンス管理ツール
パフォーマンスデータコレクション


設計フェーズ

パフォーマンス管理ツール開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• パフォーマンスデータコレクション
– SQL ServerやOSのパフォーマンス情報を収集
– 過去データも参照可能（SQL Server2008）
– OracleのEnterprise ManagerやStatspackと同等


設計フェーズ

パフォーマンスデータコレクション開発フェーズ
開発フェーズ
運用フェーズ
運用フェーズ

• クエリ統計
– 負荷の高いSQLTOP10の抽出が容易

•クエリ統計によるレポート画面
• 実⾏時間の⻑いSQL
• CPU使用時間の⻑いSQL
• 物理読み込みの多いSQL
• 論理書き込みの多いSQL


3.まとめ
3.まとめ


まとめ

• データを格納するハコとしてはどのデータベー
スも同じ
⇒僅かな機能差や実績が製品の差になっている
• 違いを理解することで、適材適所にデータベー
スを配置することができる
更に・・・

・お客様に対して攻めの提案が可能
・設計・開発時の手戻り削減
・運用後の障害発生を回避

•Copyright © 2011 Insight Technology, Inc. All Rights Reserved. 57

ひとつのデータベース技術だけでは生き残れない


[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)

More Related Content

What's hot

Viewers also liked

Similar to [INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)

More from Insight Technology, Inc.

Recently uploaded

[INSIGHT OUT 2011] C12 50分で理解する SQL Serverでできることできないこと(uchiyama)