Oracle設計

初めてのOracle設計

株式会社アイ・ティ・プロデュース
塩原浩太

Copyright © 2012 Kouta Shiobara, Inc. All Rights Reserved.

免責事項

• 本資料の内容及び発言は、私個人のものであり
所属会社や所属団体の見解を反映したものでは
ありません。

• 本資料に記載されている内容が設計の全てでは
ありません。また、例示が全てでもありません。

Copyright © 2012 Kouta Shiobara, Inc. All Rights Reserved. 2

自己紹介

株式会社アイ・ティ・プロデュース所属
http://www.it-produce.co.jp/

データベース業界数十年のエンジニア
メインはOracle Database、OSS系もちらほら

技術ブログ：Trying Database
Twitter:@sora_to_umi

座右の銘：格物致知


本セッションの目的とフォーカス

• 目的
– Oracle 設計の内容を注意点を知る
– Oracle 設計に対する漠然とした不安意識の払拭

• フォーカス
– 非機能要件周り(物理周り)


システムカットオーバの流れ

• 企画
• RFP作成
• 要件定義
• 基本設計
• 詳細設計
• 構築
• テスト
• 移行
• カットオーバ
• (運用)


設計の流れ

要件定義
要件
基本設計具体化
あいまい、方針
不明な要素は
戻って確認詳細設計
値
設定定義


設計フェーズにおける実施内容

• システムの目的、企画の整理
要件定義 • 要件決定

• 要件の整理
基本設計 • 構成、方針の決定

• サイジング
詳細設計 • 設定値の決定

• 導入時の設定書
設定定義書 • 各種設定の設定結果


要件定義

要件定義：一番のインプット
– 求めるものを明確にする
– 気付いていない自分の要求を明確にする要件
– 何を優先するかを明確にする
必要な
困ってこと
いること

あると
いいな

要件定義


代表的な要件

• 性能要件
– 同時処理件数、レスポンス
• 可用性要件
– RTO,RPO,RLO,稼働率、多重障害
• 拡張性要件
– スケールアップ、スケールアウト、リプレイス
• キャパシティ要件
– 目標使用率
• セキュリティ要件
– 監査、アクセス制御、暗号化
• 運用要件
– 監視、メンテナンス
などなど


要件定義で気を付ける点

• 顧客は技術のプロではない
• 設計する側は対象システムのプロではない
• 顧客と協力して要件を明確にすることが大事
• 現行踏襲の罠に嵌らない
• 数値、とても大事(件数、秒、人、、、)


基本設計

基本設計：構成や方針を決める
– 要件の整理、
• 要件のOracle視点での落とし込み
• システムの理解
– 作戦・戦略を決める
• 他チーム(Oracle以外の要素)との切り分け
• Oracleの設計方針、構成決定


要件の整理(システムの理解)

内容、目的 DBの位置づけ

要件定義書

重要度、影響度データ特性


要件の整理(要件のOracle視点での落とし込み）

• 要件定義書はOracle DB向けに書いてあるわけでない

• Oracle DBでもその要件を満たす必要があるか精査が必要

例)
監査証跡、暗号化、システムが使われるのは昼間だけ


作戦・戦略を決める
他チーム(Oracle以外の要素)との切り分け

• 要件をどこで担保するか
• 要素は重複、連携してる

AP
ハードストレージネットワーク
サーバ

OS Oracle 運用


作戦・戦略を決める
Oracleの設計方針、構成決定

• 何が必要か
• 何が起きるかをイメージする
– どんな使われ方する？
– 将来的なボトルネックは？
– 運用していくとどうなる？
メモリ

I/O CPU


構成・方式

• HA?RAC? DG?レプリケーション？
• EE? or SE?
• パーティショニング?圧縮?
• ASO?DBV?OAV?
• Diagnostics Pack? Tuning Pack?
• ホットバックアップ?コールドバックアップ?
• RMAN?Fast Recovery Area?


ちゃんと考えてみる
• SE-RAC
– リソースの有効活用？
– スケールアウト出来る？
– 止まらない？
CPU使用率40% CPU使用率40% 稼働率99%
× 稼働率99%

CPU使用率80%


システム全体で考える

• 本当に冗長？

DNSサーバ

SCAN SCAN
VIP1 LISTENER1

SCAN SCAN
VIP2 LISTENER2

SCAN SCAN
VIP3 LISTENER3

APサーバ


例

３．構成設計
データベースシステムでは、サーバ障害対策としてOracle Real
Application Clusters構成を採用する。
以下、表X.X.○○○に採用根拠を示す

名称説明停止時間コスト拡張性
RAC構成・複数のサーバでデータベースを共有、起動する 10~30秒 △ ○
・特定サーバ上で障害が発生した場合でも、残りのサーバでサービス
継続が可能。
・H/Wリソースの有効活用が可能。
・リソース不足の際には、スケールアウトが可能
・ライセンス費用は稼働サーバー数分必要。

HA構成・稼働系、待機系でデータベースを共有。(Active & Standby) 10秒～1分 ○ △
・稼働系に障害が発生した場合には待機系切り替わり、
早期サービス復旧が可能
・枯れた技術
・ライセンス費用は稼働系1台分のみ。


基本設計で必要なこと

• 知識
– Oracle DBの各種機能(とそのシステム要件)
• 高可用性機能、パフォーマンス関連機能、EMのオプション
– EEとSEの標準機能の差異
• パラレルクエリ、オンラインリビルド、
– ハードやストレージ、バックアップ機能

• 参考資料
– Oracleライセンスマニュアル
– 各種OTN資料(セミナー資料やホワイトペーパ)
– ハードベンダー資料(ベストプラクティス的な。。)

• 検証
– 作ってみる、やってみる


詳細設計

詳細設計：DBの構成要素/方針、詳細を決める
– データベースを作成するのに必要な要素
– データベースを使うのに必要な要素
– データベースを安全に使っていくのに必要な要素

設定定義書


DB作成に必要な要素

• 物理設計
– データブロック設計
– エクステント管理設計
– セグメント管理設計
– 領域サイジング※
– 表領域設計
– レイアウト設計
– パラメータ設計

※概算はもっと上位の工程で完了している


使うのに必要な要素

• ネットワーク接続設計
– リスナーやフェイルオーバ、ロードバランスなど
• ユーザ設計(役割、権限)


DBを安全に使っていくのに必要な要素

• セキュリティ設計
– 監査機能
– パスワード管理
– 暗号化設計
• 運用設計
– リソース監視設計(障害、リソース、パフォーマンス等)
– メンテナンス(索引やフラグメント、ログ、パッチ適用等)
• バックアップリカバリ設計
– 取得方法(方法、対象)
– サイクル、世代
– リストア、リカバリ方法


サイジングで悩み過ぎない

• 根拠は必要(これ絶対)
• どっかから持ってくる
– 既存環境
– 過去案件
– SPECint
• 分からないものは分からない
• 仮定する
• 足す、引く、掛ける、割る


ファイル配置をちゃんと考える

• SAME（Stripe And Mirror Everything）?
• REDOログ・ファイルのメンバ
• アーカイブREDOログ・ファイルのdest
• バックアップ

例)
DBファイル群のLVをストレージコピーで日次バックアップ
リストアは、LV単位
RPOは限りなく直近まで？？？

RMANでバクアップからのスナップミラー？


パラメータ設計

• DB作成後に変更不可のもの
– キャラクタセット、ブロックサイズ
• テストの結果で簡単に変わる(変更する)もの
– メモリ系のパラメータ、REDOログファイル関連
• デフォルト値じゃ駄目？
– セキュリティ関係、領域管理


詳細設計書例

8-2-1.エクステント管理方式
エクステントとは、複数の連損くしたデータブロックの集合から構成される。Oracleデータベース
の領域割り当て単位。
エクステント管理方式にはディクショナリ管理方式とローカル管理方式が選択可能だが、本システム
ではローカル管理方式を採用する。採用根拠とそれぞれの管理方式の特徴を表XXX, △ △ △に示す。


詳細設計で必要なこと

• 知識
– Oracle DBのアーキテクチャ
• 動作、メモリ構造、領域管理方法
– 各種機能に付随する考慮事項や制限
• 選択方式、必須要件、機能同士の組み合わせ
– パラメータ
• 初期化パラメータ、動作

• 参考資料
– 各種マニュアルや技術本
– 各種OTN資料(セミナー資料やホワイトペーパ)
– ググる？

• 検証
– 作ってみる、やってみる


余裕率や安全率は悪か？

• 様々なことが考えられる
– 予想外のデータ増加や処理増加(商売繁盛)
– システム追加(処理追加)
– メンテナンス(フラグメント解消)
– リストア
– チューニング(マテリアライズドビュー)

• 問題
– 色々なチームで掛け算してる内にありえない値に
⇒他のチームと連携する
– そもそもの母数が大きい
⇒常識的に考える


設計書作成にまつわるエトセトラ

• 設計書そもそも必要？
– DBが作れればいいというものではない
– 未来のためにも必要
• 設計書みんなで書く？一人で書く？
– 重複は排除する。参照する。
– Oracle関連の設計書を大人数で書かない
• 設計書≒設定定義書
– 根拠・方針・思想≠設定値


まとめ

• インプット大切
• 仲間大切
• 想像力大切
• 意味ある設計が大切
• サイジング悩み過ぎないのが大切
• アーキテクチャ・機能に関する知識は大切
• 迷ったり・分からなかったら検証するのが大事
• 設計書大切


考察

• そもそもなんでOracle DBだったんだっけ？
• RDBMSの性能差・機能差＝システムの差？
• 構成や機能の選択肢が少ない方が設計楽なんじゃ？？

• そもそもなんでRDBMSなんだっけ？？

• そもそもなんで自前で作っちゃうの？？


次回予告

•PostgreSQLとOracleの
設計比較

comming soon…


Oracle設計

More Related Content

What's hot

Viewers also liked

Similar to Oracle設計

Oracle設計