Oracle DatabaseとMySQLは「何」が違うのか 「アーキテクチャの違い」を理解する：実践 OSSデータベース移行プロジェクト（2）（1/3 ページ）

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は「Oracle DatabaseとMySQLのアーキテクチャの違い」を解説するとともに、正しい設定／移行計画に向けたポイントを紹介します。

[廣濱顕司, 荻野邦裕, 潮雅人，SCSK株式会社]

連載バックナンバー

　前回は、Oracle Databaseなどの商用データベース管理システム（DBMS）製品から、オープンソース（OSS）DBMSである「MySQL」への移行を検討する企業が増えつつあることと、実際に移行するならば「具体的に、何を行っていくのか」の項目内容を説明しました。

　今回は、DBMSの移行で「データベース管理者やアプリケーション開発者が、新しいDBMSを正しく扱う／構築する」ために必要となる、移行元のOracle Databaseと、移行先であるMySQLの「アーキテクチャの違い」を理解しましょう。

　大きく分けて、以下の7つのポイントをチェックします。

1. インスタンス
2. ユーザー
3. 権限とロール
4. 表領域管理
5. 監査
6. ロックとトランザクション分離レベル
7. オプティマイザ

【1】「インスタンスの違い」を理解して、正しく設定する

　Oracle DatabaseとMySQLのインスタンスは、以下のように違いがあります（図1）（図2）。

図1　Oracle Databaseのインスタンスと物理ファイル構成

図2　MySQLのインスタンスと物理ファイル構成

　データベースの移行を行う上では、データベースの中身を移行する前に「メモリ関連のパラメータを正しく設定する」ことが不可欠です。そのため、アーキテクチャの違いを正しく把握しておくことが重要です。

　Oracle Databaseのデータベースバッファキャッシュは、MySQLでは「InnoDBバッファプール」に、Oracle DatabaseのREDOログバッファは、MySQLでは「InnoDBログバッファ」に当たります。名称／呼称は異なりますが、基本的にこれらの役割は同じです。

　Oracle Databaseには自動メモリ管理機能があります。sga_target（Oracle Database 10gR1以降）やmemory_target（同11gR1以降）を指定することで、SGA（System Global Area）内のメモリ配分はOracle Databaseが自動的に設定してくれます。

　一方のMySQLでは、innodb_buffer_pool_sizeやinnodb_log_buffer_sizeなどのパラメータを「データベース管理者（DBA）が指定」する必要があります。

　このうち、特にMySQLのパフォーマンスに大きく影響するのがinnodb_buffer_pool_sizeです。innodb_buffer_pool_sizeでは、MySQLのデータ／インデックスが保持されるメモリ領域のサイズを指定します。一般的には、サーバに搭載される物理メモリ量の70〜80％程度を目安にして値を設定します。

　メモリ関連のパラメータは、他にもkey_buffer_size、read_buffer_size、sort_buffer_sizeなどがあります。これらのパラメータと比較すると、上記のinnodb_buffer_pool_sizeは圧倒的に大きなサイズを占めていますし、そもそもDBMSの設計において「データやインデックスをキャッシュできる領域のサイズは最重要設計要素である」と考えられることから、innodb_buffer_pool_sizeを的確に設定するだけでも十分な性能を得られるでしょう。

ポイント

• innodb_buffer_pool_sizeやinnodb_log_buffer_sizeなどのパラメータは、DBA自身が指定する
• 特に、innodb_buffer_pool_sizeのパラメータはパフォーマンスに大きく影響する
• innodb_buffer_pool_sizeは「サーバに搭載される物理メモリ量の70〜80％程度」の値を設定する

【2】「ユーザーの違い」を理解して、正しく設定する

　Oracle Databaseにおける「ユーザー」は、データベースへのアクセス制御の他に、オブジェクトの所有者としての用途もあります。一方のMySQLでは、「アクセス制御のみ」を行います。MySQLには、オブジェクトの所有者という概念はありません。

　なお、MySQLの内部的には、「ユーザー名と接続元の組み合わせ」を1つのユーザーアカウントとして解釈します。例えば、「ap_user@192.168.0.1」となります。これは、「ap_user」というユーザーが「192.168.0.1」のサーバから接続する際に利用されるユーザーアカウントである、という意味となります。

　このため、Oracle DatabaseからMySQLへの移行においては、「オブジェクトの所有者」という概念を考慮する必要はなく、どんな名前のユーザーがどのサーバ／クライアントからアクセスしてくるか、というシンプルな考え方でMySQLのユーザーアカウントを作成すればよいことになります。

　もう1つ、Oracle Databaseには「プロファイル」と呼ばれる、ユーザーごとにリソース制御やパスワードポリシーを指定するための仕組みがあります。対してMySQLでは、Oracle Databaseのようにユーザーアカウントごとのリソース制御はできません。

　しかしパスワードポリシーについては、MySQL 5.7からvalidate_passwordプラグインがデフォルトで有効（*1）となっています。こちらを利用することで、ユーザーごとにパスワード要件を指定できます。パスワード要件は、サーバ変数のvalidate_passwordで始まるパラメータを指定することで変更できます。

*1：validate_passwordプラグインが自動的に有効になるのは、Red Hat Enterprise Linux上でのRPMインストールの場合です。ソースファイル／tarファイル展開でインストールする場合には、手動で有効にしてください

ポイント

• MySQLの「ユーザー」は、「アクセス制御のみ」を行う役割を持つ
• 内部的には、「ap_user@192.168.0.1」のように、「ユーザー名と接続元の組み合わせ」を1つのユーザーアカウントとして解釈する
• MySQLには「プロファイル」の概念がない。ユーザーアカウントごとのリソース制御はできないが、「パスワードポリシー」は個別に指定できる