DBA データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > カテゴリー - DBA

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

DBAは、開発プロジェクト側に居るべき? それとも運用側に居るべき?

JPOUGのadvent calendar 12月4日担当です。いやー、ぎりぎりの時間です。
http://www.zusaar.com/event/1687004

DBAは通常、DataBase Administratorの略とされます。
最近、DBAの定義について考えることがあったので、そのネタで書いてみたいと思います。

Administratorという定義から考えると、管理者、運用者というイメージです。しかし、DBA(もしくはDB担当)というのは、私が知る限り、開発プロジェクトに所属していることもありますし、運用部隊に居ることもあります。技術支援部隊に居ることもあります。

開発側に居るDBAはどんな仕事をしているのでしょう?
こんな仕事ではないでしょうか?
・方式設計のDB周りの作成
・物理設計(インスタンス、オブジェクト)
・オブジェクト作成(表、インデックス)
・サイジング
・DBアカウント作成
・DB運用設計
・SQLチューニング(単体テストなど)
・テスト(障害テスト、バックアップリカバリ)
・性能分析とチューニング(性能テスト)
・エラーの対応
・ベンダー問い合わせ
・オブジェクト変更(表定義変更、インデックス定義変更)
・DB手順作成やレビュー
・集積パッチ適用
・個別パッチ適用

運用側に居るDBAはどんな仕事をしているのでしょう?
こんな仕事ではないでしょうか?
・開発プロジェクトのレビュー
・システムの受け入れ
・定期メンテナンス(ログメンテ、再編成など)
・ヘルスチェック
・SQLチューニング(遅いSQLのチューニング)
・DBアカウント作成
・キャパシティ管理
・インシデント対応(エラーの対応含む)
・オブジェクト変更(表定義変更、インデックス定義変更)
・DB手順作成やレビュー
・集積パッチ適用
・個別パッチ適用
・バックアップリカバリ

いろいろやることありますね。よく見ると、被っているものも多くあります。どちらがいいのでしょうか? メリットとデメリットを挙げてみましょう。

開発側のメリットとデメリット
・DB担当を雇いやすい(運用予算は厳しい)
・設計からサービスインまでを経験できる
・プロジェクト中は忙しい
・プロジェクト後、DB担当が居なくなるケースがままある(というか、そういうプロジェクトばかり。。。)

運用側のメリットとデメリット
・運用品質の向上が見込める
・複数のDBを一人が見ることで、コストも削減できる(はず)
・複数のDBを一人が見ることで、スキルアップができる
・トラブル時以外は、マイペースで仕事ができる(はず)
・運用に専念しているので、プロジェクトに人を取られない。
・運用側は立場が弱い(開発プロジェクトの立場が強い)ことが多い
・ある程度やると飽きてくる人もいる

どちらにDBAを置くべきかは、現場(や会社)によると私は思います。
おそらく、運用を強くしたいのであれば、運用側にDBAを置き、開発を強くしたいのであればプロジェクト側におくべきでしょう。
たとえば、大きな開発プロジェクトでは、開発が大変であるため、開発側に複数名、DBAが居るべきです。
大きなシステムセンターでは、複数のシステムを束ねる運用のDBAも居るべきです。
統合DBでは、運用のDBAはほぼ必須でしょう。これは、統合DBは、最初の切り分けやお守りを統合DB担当が行うためです。
小さな開発プロジェクトでは、DBだけ考えればいい専任DBAを置く余裕はないので、兼務になってしまいます。そのため、運用フェーズになったら、運用部隊の専任のDBAに複数のシステムを見てもらうのが理想です。保守契約上、それが無理なことも多いですが。。。。

U.S.でDBAが確立している1つの理由は、自社開発がよく見られるからだと議論したことがあります。
SIerという仕組みがある以上、開発が終ってもSIerに頼むことが多く、運用の専任DBAを置けることは少ないように見えるからです。
ただ、SIerを活用する場合でも、ユーザー側に運用の専任DBAを置くべきケースがあります。それは、運用の高品質を目指す場合とトラブルが多発している場合です。その場合、ユーザーが強くなる必要があると思います。

とりとめもなく書いてみました。
この年末に、理想のDBAや、やるべきDBAのタスク、来年の自分のキャリアを考えてみてはいかがでしょうか。
スポンサーサイト
[ 2013/12/04 23:05 ] DBA | TB(0) | CM(3)

TechTalkNight #2 でいただいた質問への回答

■アンケートに質問いただいた内容

背景
- v$sysstat を使って前日と当日のシステムの状態を比較しましょうとアドバイスがありました
- v$sysstat は executions とか logon数とか 100 行近くのパラメータが累積値で保持されていると理解しています
- この項目をすべてエクセル化するのは難しいと考えています

教えていただきたい点
- 監視の項目で特に注視する項目はありますか
- 通常 v$sysstat は何分間隔で取得されますか
- 待機イベント等を監視する際、参考とする表、項目を教えていただけますと助かります

- 本日も大変有意義な会を開いていただきありがとうございました
- 次回も参加させていただけますと大変うれしいです

■回答

質問ありがとうございます。回答します。

v$sysstatは各種処理量が分かるので、v$active_session_historyとの
合わせワザで分析が進む、とても便利なビューです。
v$sysstatは、30秒か1分間隔が個人的にはお勧めです。
スクリプトは、このようなものがサンプルです。値が0の項目は記録しないようにします。障害時を考えると、値が0以外の項目は全部取っておいた方がいいと思います。

#!/bin/sh

#本スクリプトおよびSQLの内容、
#および利用したことによって生じた損害等について、
#日本オラクルおよび著者は
#一切の責任を負いません。自己責任でご使用ください。
#また、筆者個人のノウハウであるため、
#お問い合わせもご遠慮ください。
#
#特に、スクリプトやSQLを改変した場合の性能へのインパクト、
#データを取得したことによるディスクフル、
#パスワードのセキュリティ漏洩などにはご注意ください。

SLEEP_SEC=30
LOOP_MAX=120
COUNT=0

echo "/"
echo "set heading off"
echo "set feedback off"
echo "set pagesize 9999"
echo "set linesize 2000"

while [ $COUNT -lt $LOOP_MAX ]
do
echo "@sysstat.sql"
sleep $SLEEP_SEC
COUNT=`expr $COUNT + 1`
done


○sysstat.sqlの中身

SELECT to_char(sysdate, 'MMDDHH24MISS')||','||NAME||','||VALUE
FROM V$SYSSTAT
WHERE VALUE > 0;

#このスクリプトは8年くらい前にDBマガジンに投稿した内容です。続・門外不出の現場ワザに収録されています。エクセルグラフ化用perlスクリプトなどもありますので良かったら見てみてください。


分析項目ですが、特に注目するのはexecute countとconsistent getsです。
それ以外の項目は通常時にはグラフ化する必要はないと思います。
障害時には、v$sessionと付け合わせながら、いろんな項目を見ます。
キャッシュフュージョンの失敗とか、ご指摘のlogon数とか、通信データ量とか。

> - 待機イベント等を監視する際、参考とする表、項目を教えていただけますと助かります
待機イベントを監視する際には、アクティブなセッション数を見るのが、
分かりやすいと思います。
EMでも監視グラフがあります。「何かおかしい」というのが分かりやすいです。

次回もぜひご参加ください。
[ 2013/09/13 21:04 ] DBA | TB(0) | CM(0)

IT業界の痛いところ衝いているブログの紹介

少し前も紹介した、知り合いのエンジニアが書いているブログの当面のシリーズ(IT業界の痛いところ衝いていると思います)が一段落したようなので紹介です。Oracle使いでも現場の感覚まではご存じない方もいらっしゃると思います(例:プリセールスやサポート)。現場ってこんな感じなのねーと実感するにもいいブログと思います。
  「クラウド業者は鼠小僧?」DBサーバーのthin provisioningと重複排除の使い分け
  「リソース(ディスク領域)をリニアに追加するには?」
  「買い過ぎるのは見積もりが下手だから???」
  「罪深きエンジニアたち」  不安に思う人の心理が積み増すオーバーヘッド

よかったらどうぞ。
[ 2012/02/19 21:50 ] DBA | TB(0) | CM(1)

Oracle11gR2 XE (無償版)

しばらく前ですが、11gR2のXE版が公開されています。
これは、パッチは出ない代わりに、無償で使えるエディション(版)です。
本質的な機能は揃っていますし、比較的軽いですし、インストール簡単ですし、
自分のPCに入れて勉強用に使うのに最適です!
なんと、16分でインストールできました。

10gのXE以降数年ぶりのリリースです。自分のPCに入れてみました。

まず、以下のURLからメディアをダウンロードします。
http://www.oracle.com/technetwork/jp/database/express-edition/downloads/index.html
サイズは320M程度です。

注意:10gのXEがインストール済みの場合は、「アプリケーションの追加と削除」から
   削除を実行しておくこと。

DISK1 setup.exeをクリックします。あとは、パスワードの入力を除くと、
そのままクリックを繰り返していく程度です。20分程度で終わるでしょう。

なお、自動起動にしておくとWindowsが重いので、使わない時は、
サービスを止めておきましょう。
「コントロールパネル」の「管理ツール」の「サービス」から操作できます。
#サービスの名前が「OracleXE・・・」や「Oracle・・XE・・・」となっているものです。
#スタートアップを「自動」から「手動」に変えましょう。

管理画面はこんな感じです。11gR2XE.jpg


勉強用にいかがですか?
[ 2011/11/13 01:44 ] DBA | TB(0) | CM(0)

DBA3タイプのスキルアップ方法

[ 2011/08/26 03:12 ] DBA | TB(0) | CM(0)
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。