こんなお悩みはありませんか?

  • 性能で困っているが、パッケージソフト等を導入していてアプリケーションの改修が出来ない…
  • 現行DBのパフォーマンスが一向に改善されない…
  • フラッシュストレージを検討しているが、どのストレージを選んで良いのか分からない…

システムエグゼのDBチューニングサービスが、このようなお悩みを解決いたします。

特長

01

長きに渡り管理者を悩ませてきたパフォーマンス問題を解決し、安定したシステムを実現

お客様の環境に最適なデータベース設計をご提供いたします。

02

OSとDBのパフォーマンス情報から性能改善策のアセスメントを実施
(アセスメント実施後に、DB&SQLチューニングを実施)

ベストパフォーマンスを引出すチューニングを実施します。

インスタンス・DBチューニング

チューニング対象SQLの改善案提示

03

ディスクI/Oがボトルネックになっている場合には
「フラッシュストレージ」にてパフォーマンス問題を解決

フラッシュストレージの導入により、さまざまな問題を解決します。

フラッシュストレージの導入メリット

ビジネス・アプリケーションに手を加えること無く高速化が可能

IOのボトルネックを解消

従来の2-10倍高速化

シンプルで高速なインフラだからこそできるコスト削減

ストレージ管理を簡略化

ストレージ管理を簡略化
  • ブロックサイズの考慮不要
  • LUNについての考慮不要

DBインスタンスの増加を防ぐ

DBインスタンスの増加を防ぐ
  • 柔軟なスナップショット機能の活用で、
    テスト/開発/分析といったものは不要

サーバ台数を削減

サーバ台数を削減
  • サーバー台数の低減
  • DBライセンスの低減
  • チューニング不要
  • 消費電力の削減

データベースの圧縮や暗号化処理は不要

データベースの圧縮や暗号化処理は不要
  • 暗号化、圧縮に使うCPUが不要
  • 暗号化、圧縮に必要なライセンスコストが不要
お問い合わせはこちら

利用手順

本サービスは3段階のステップでサービス提供をしております。

STEP1アセスメント

お客様の環境を調査し、評価レポートを提示。
必要であれば検証環境等でPoC(実機検証)確認。

ポイント

必ずアセスメント行うので、導入効果を確認してから購入検討が可能

STEP2設計・構築・DB移行

フラッシュストレージ設計・構築を実施(フラッシュストレージを導入する場合)。
完了後、現行DB領域をフラッシュストレージ領域へ移行。

ポイント

・オープン系のDB(Oracle, SQL Server, MySQL, PostgreSQL, DB2)の移行に対応
・スポット対応等、お客様のご要望に応じて作業を実施することが可能

STEP3運用・保守

フラッシュストレージおよびDBの運用保守。

システム構築例

Oracle

フラッシュストレージ上でOracle DBを稼働させる為に、新環境のDB構築から既存環境のデータ移行を行います。
業務停止時間やお客様のご予算によって移行パターンを提案いたします。

5つの移行パターンをお選びください。

移行パターン 概要 作業
コスト
追加
ライセンス
業務停止
時間
特記事項
1.GoldenGate GoldenGateを用いてデータを同期し、移行当日に新DBへ切り替える。

GoldenGateで同期するための制約があり、同期出来ないオブジェクトもある。
2.DataGuard OracleのDataGuardを用いてデータを同期し、移行当日に新DBへ切り替える。 Oracleのバージョンを新・旧DBで合わせる必要がある。
3.ASMミラーリング Oracleの標準機能であるASMミラーリングを用いてフラッシュ領域を追加⇒リバランス⇒同期後に既存領域をASMミラーリング対象から切離すことで、無停止でフラッシュストレージへ移行。 OracleDBがASM環境で定義されている必要があり、リバランス中はストレージにI/O負荷が掛かる。
4.マテビューレプリケーション Oracleの標準機能であるマテリアライズドビューを用いてデータを同期し、移行当日に新DBへ切り替える。 同期する際にアーカイブログが肥大化するため、同期間隔等の調整が必要。
5.バックアップ・ダンプ バックアップやexpdpを用いて新DBへデータを移行。 データの整合性のため、静止点を設ける必要がある。

1.GoldenGate

切替直前までデータを同期し、切替当日にAPサーバを切り替える。

切替直前までデータを同期し、切替当日にAPサーバを切り替える。

2.DataGuard

切替直前までデータ同期し、別環境側のDBを設定してAPサーバの接続先を切り替える。

切替直前までデータ同期し、別環境側のDBを設定してAPサーバの接続先を切り替える。

3.ASMミラーリング

新規でフラッシュストレージのディスクをASM領域に定義し、リバランス(データ再配置)後に既存ストレージディスクASM領域から削除して切り替える。

新規でフラッシュストレージのディスクをASM領域に定義し、リバランス(データ再配置)後に既存ストレージディスクASM領域から削除して切り替える。

4.マテビューレプリケーション

切替直前までデータ同期し、オブジェクト変換(マテビューからテーブル)後にAPサーバの接続先を切り替える。

切替直前までデータ同期し、オブジェクト変換(マテビューからテーブル)後にAPサーバの接続先を切り替える。

5.バックアップ・ダンプ

データ整合性のため、現行環境で静止点を設けてDBデータを取得し(バックアップ、expdp等)、新環境へデータを投入後(リストア、impdp)APサーバの接続先を切り替える。

データ整合性のため、現行環境で静止点を設けてDBデータを取得し(バックアップ、expdp等)、新環境へデータを投入後(リストア、impdp)APサーバの接続先を切り替える。

SQL Server

フラッシュストレージ上でSQL Serverを稼働させる為に、新環境の構築と現行環境からのデータ移行を行います。
業務停止時間やお客様のご予算によって移行パターンを提案いたします。

3つの移行パターンをお選びください。

移行パターン 概要 作業
コスト
追加
ライセンス
業務停止
時間
特記事項
1. バックアップ・リストア 切り替え前にバックアップから新DBへデータを移行し、切り替え当日まで定期的に差分データを反映させる。

オンラインで実行可能であるが実行負荷とバックアップ分の容量が必要。
2. エクスポート・インポート 事前にオブジェクトをSQLで作成し、データを当日に移行する。 個別に移行することができるため柔軟であるがデータの整合性のため、静止点を設ける必要がある。
3. デタッチ・アタッチ 現行から移行対象のデータベースを一時的に切り離し(デタッチ)、データベースファイルをコピーして、新環境に取り付けて(アタッチ)データを移行する。 手順は簡略であるが、DBを停止する必要がある。

1.バックアップ・リストア

移行前日までにバックアップを新環境にリストアし、移行当日までの間は定期的にデータ同期(差分データ反映)を行い、移行当日にAPサーバの接続先を切り替える。
定期的同期をすることで、切り替え時の業務停止時間を短縮できる。

移行前日までにバックアップを新環境にリストアし、移行当日までの間は定期的にデータ同期(差分データ反映)を行い、移行当日にAPサーバの接続先を切り替える。定期的同期をすることで、切り替え時の業務停止時間を短縮できる。

2.エクスポート・インポート

事前にオブジェクトのみをSQLで作成し、移行当日に静止点を設けてデータ移行後に、APサーバを切り替える。

事前にオブジェクトのみをSQLで作成し、移行当日に静止点を設けてデータ移行後に、APサーバを切り替える。

3.デタッチ・アタッチ

移行当日に現行環境のDB停止後にデータベースを切り離す(デタッチ)。
データベースファイルを新環境にコピーし、新環境でデータベースを取り付け(アタッチ)、APサーバの接続先を切り替える。

移行当日に現行環境のDB停止後にデータベースを切り離す(デタッチ)。データベースファイルを新環境にコピーし、新環境でデータベースを取り付け(アタッチ)、APサーバの接続先を切り替える。
お問い合わせはこちら