#odc16 パナソニックインフォメーションシステムズに聞くOracle Databaseに最適なインフラとは? @Oracle Database Connect 2016まとめ

「Oracle Database」のエンジニアを対象にデータベース運用のためのテクニックなどに関するノウハウを紹介するイベントOracle Database Connect 2016に参加してきました。

その時のパネルセッションのまとめです。

OracleDatabaseを徹底的に使い倒すコツとは？

統合に至った経緯

• 課題
  • 大量にDBサーバが存在することで、運用工数が多大だった
  • 利用ユーザ増加でレスポンスが遅延してきた
  • 夜間パッチの処理悪化でオープンが遅延してきた
• 方向性
  • 同一プラットフォームで管理台数を極力減らした
  • データの爆発的増加、複雑な処理の増加に対応できるインフラの構築
  • →Exadataを導入することに

統合時に考慮したポイント

• 集約して既存システムのパフォーマンスが大丈夫か
  • →リソース制御を利用する
• アクセス制限によるデータ保護
• DBノードの完全分離
• マシンパワーに頼ったアプリケーション設計の禁止
  • →開発環境のCPUリソースを0.5%に制限してテスト時にパフォーマンス課題を解決した
• ダウンタイムの最小化
  • 統合するとメンテナンスで落とさないといけないことがたまにあるので、統合した分だけシステム停止がおこってしまうのでそれをできるだけ避けるようにした
  • プライマリDBとスタンバイDBをDataguardとinfinity bandで結線してほぼリアルタイムでログを転送した

統合のSTEP

• スキーマを統合し、マルチラック化した
• 開発と兼務のDB運用を組織化された専任DBAに変えた
• パーティショニングや圧縮機能を最大限使った
• 新規スキーマを15分で提供できるようになった
• その後、マルチテナント化した

システムリプレース概要

• リソースが足りていなかった状況がリプレイス後、最適なリソース使用で安定した稼働を実現した
• 1つのCDBで38個のPDBが動いています
• 現在は容量重視型の統合DBを計画中

安定したサービス提供のためのDBA組織化

• 組織化前はアプリ担当がDBを含む全てを担当していたが、運用品質低下していた
• 組織化後
  • アプリは用意されたインフラで保守・運用性を考慮した設計を行うことに
  • DBAは統一/統合化されたインフラを構築・運用し、安定したインフラサービスの提供と効率的な運用を行う
  • 障害対応、パフォーマンスチューニングをナレッジ化し、属人的にならない運用を実現

統合DB、専任DBAは組織導入による成果

• 運用標準化によるコスト・品質の最適化
  • 運用工数を1/15に効率化
• ハードウェア、ソフトウェアのコスト削減
  • ライセンス、保守サポート集約により合理化を実現
• IT全般統制への対応
  • 定義変更、データ更新トラブルが0に。

FAQ

運用について

DBA専門チームを組織化し、統合基盤を安定運用するためのポイントは何か？

• 専任チームなので、安定運用するために方向性を失ってしまうかもしれないため、誰よりもDBの機能を理解しているのが重要
• DBが疎い人を育てるとアプリに行ってしまうことがあったが、あまりメンバーを変えないことが大事
• DBで障害が発生した時に、インシデントをクローズにもってくまでにDBAを納得するまで調査を継続する。

アプリ開発者との連携やすみ分けはどのようになっているか？

• DBAは開発環境と本番環境を別に持っているが、開発環境をアプリに渡している
• 処理方式やチューニングの支援要請があがったりするが、それにたいしてDBAチームが支援する
• 本番環境は依頼にもとづく変更作業をDBAがやる
• EMでの監視などをしていて、問題が上がったらアプリに渡している

DB統合の勘所とは？

マルチテナントを活用して、DB統合の手法や運用がどのように改善されることを期待しているか？

• 最初はスキーマ統合を進めようとしていて、スキーマ名を変えた時のアプリケーションの開発工数がかかったりしたが、マルチテナントを使うことで同じスキーマでも使えるのが良かった
• PDBごとでパラメータがいじれるのが良かった
  • bind_peekをonにしたりなど、cursor_shareingをoffにしたりなどしていたが、PDBにすることでシステム単位でオプティマイザパラメータを変えたりなどできるようになった
• PDB単位で分割はできているが、SGAについては一つのCDBで共有にしてしまっているが、一つのPDBが大きく使うと別のPDBでメモリが足りないと起こったり、クラッシュしたり、再起動してしまったりしている
  • →再起動によってサービスに影響がある

なぜ、マスターデータは個々のDBではなく、共通のDB（PDB)として活用しているのか

• データ量、メンテナンス性がある
• それぞれのシステムが12cにいくと同じデータをもっていても無駄に容量を使ってしまうので一つにした
• Aの仕組みのマスターを使うときはDBリンクやshared linkを使ったりする
• みんながアクセスするデータは一つのPDBに持って行った
• DB linkだと若干実行計画が不安。
• 全てのPDBが共通にアクセスできるような機能が欲しいと思っている

安定運用に欠かせないものとは？

基盤構築や安定運用ににむけて活用しているサービスは何か？

• OracleEnterpriseManager CloudControlをつかっている
• 監視としても使っているが、TopActivityScreenを使っている
  • オンラインでパラメータをいじったりするときはOEMで見たりしている
  • 急にライブラリキャッシュの待機イベントが増えたりなど気づけたりする
• 一般的には容量など、80%で警告90%以上でクリティカルアラートを出しているが、普段のアクセスと比べて少しでもアクセスが増えた時にメールが飛ぶようにしている。

パッチ適用やプロアクティブなサービスを活用していますか？

• AWRの生データをツールを作ってグラフ化して、チーム内でMTGをする時に見て長期的なスパンで議論している
• パッチ適用はクリティカルなissueがあったり、SQLが通らないバグなどが見つかった時はパッチをあてている
• 大きなパッチは1年に1回だが、クリティカルな物のときは年に数回
• あてるときはRACのパッチローリングを使っている

@mogmetの所感

マルチテナントを使った事例をあまり聞いたことがなかったので、貴重な事例が聞けてよかったです。

まだまだ苦難点は多そうですが、今後のマルチテナントの機能や使いやすさの拡充に期待したいですね。