Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQLのココにギョッとした! - オラクルエンジニアがMySQLを触って感じたこと

10,896 views

Published on

2016/12/13(火) 19:00 〜 21:00 に開催された MySQL Casual Talks in Fukuoka vol.6
https://mysql-fukuoka.connpass.com/event/46086/ で使用した発表資料です。

Published in: Data & Analytics
  • Be the first to comment

MySQLのココにギョッとした! - オラクルエンジニアがMySQLを触って感じたこと

  1. 1. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 1Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. MySQLのココにギョッとした! オラクルエンジニアがMySQLを 触って感じたこと 2016年12月13日 株式会社コーソル 渡部 亮太
  2. 2. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 2 今日の発表について • コーソルは東京・福岡・豊田を拠点にOracle Database を中心にしたプロフェッショナルサービスを提供してい ますが、MySQLなどのOracle Database以外のデータ ベースについても対応しています • Oracle Databaseを中心にデータベースエンジニアとし て経験を積んできたエンジニア(=私)が 初めてMySQLを使った時(主にver5.6/5.5だった)に驚いたこ とについて発表させていただきます • InnoDB、Community Editionを前提とします • 日々の業務に直接役に立つ内容ではありませんが・・・ 皆さんが当たり前と思っているMySQLの特徴をあらため て振り返る機会になれば幸いです 
  3. 3. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 3 自己紹介+所属会社紹介 渡部 亮太(わたべ りょうた) – 著書「プロとしてのOracleアーキテクチャ入門 [第2版]」 「プロとしてのOracle運用管理入門」 – 講演実績多数 – ブログ「コーソルDatabaseエンジニアのBlog」 http://cosol.jp/techdb/ – JPOUG 共同創設者、ボードメンバー – Oracle ACE (Oracle Database) – 2016年9月より東京から福岡に移住 株式会社コーソル – 「CO-Solutions=共に解決する」の理念のもと、Oracle技術に特化 した事業を展開中。心あるサービスの提供とデータベースエンジニア の育成に注力している – 社員数: 133名 (2016年12月時点) – ORACLE MASTER Platinum 11g 取得者数 47名 ORACLE MASTER Platinum 12c 取得者数 32名 取得者数 日本 No.1 (日本オラクル様Webページより) http://www.oracle.com/jp/education/omdata-171891-ja.html NEW!
  4. 4. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 4 MySQLのココにギョッとした! - Agenda • テーブル内部の物理構造が違う • ユーザー関連の概念が特徴的 • 領域管理の考え方が違う • 恐怖の「SQLモード」 • トランザクションログが2つある? • ナイーブなレプリケーション
  5. 5. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 5Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. テーブル内部の物理構造が違う
  6. 6. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 6 xxx- nnn InnoDBテーブルの物理構造 • このテーブル構造をRDBMS一般の用語では、「クラスタ化インデックス」と呼ぶ – 名称はインデックスですが、テーブルとインデックスが一体化したものと理解してください – 主キーがない場合など例外的な状況におけるルールについてはマニュアルを参照してください http://dev.mysql.com/doc/refman/5.6/ja/innodb-index-types.html • 主キー経由のアクセスが高速 主キー 001-nnn 001- 500 001- 275 275- 500 501- 630 631- 759 760- 800 801- 949 950- xxx 501- 800 801- nnn • リーフブロックに行全体のデータが格納される • 一連のリーフブロック内のデータはソートされている
  7. 7. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 7 InnoDBのインデックス • セカンダリインデックス – 主キー用以外のインデック ス – 1つのテーブルに対して複 数作成可能 • セカンダリインデックスを 使用したアクセスはあまり 効率的でない – 2回インデックスをたどる キー • リーフブロックに 主キー値が格納される セカンダリインデックス 主キー テーブル (クラスタ化 インデックス)
  8. 8. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 8 Oracleのテーブル構造(ヒープ構造) • ヒープ構造 – ブロック内の行データは特定の順序で並べられて いない • rowid – それぞれの行データにはrowidという位置情報 (アドレス)を持つ – rowidは内部的に管理される値であり、永続性が ない • 例えば、テーブルのデータ再編成を実行すると、 データに変化がなくてもrowidは変わりうる hoge foo baz fuga bar xxx yyy zzz 1 108 4 5 102 3 105 2 3 abc … (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid)
  9. 9. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 9 Oracleのインデックス hoge foo baz fuga bar xxx yyy zzz 1 108 4 5 102 3 105 2 3 abc … キー • リーフブロックに キー値とrowidが格納される インデックス (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid) (rowid)• インデックスの構造の観点では、主キーのインデック スと、主キー以外のインデックスは原則的に同等
  10. 10. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 10Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. ユーザー関連の概念が 特徴的(すぎる)
  11. 11. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 11 MySQLにおけるユーザー • ユーザーIDが<username>@<hostname> – 同一ユーザー名を指定して接続しても、異なるユーザーとして扱われる場合があ る – [経験談] ユーザー名を指定して接続に成功したが、意図せず匿名ユーザーとして 接続しておりビックリ • オブジェクトの所有者という概念がない – Oracleを含めた多くのRDBMSでは、オブジェクトの所有者という権限があり、権 限の扱いが自分のオブジェクト、他人のオブジェクトで異なる • 例) 自分のオブジェクトは全操作OK、他人のオブジェクトは権限がないと操作NGなど • ユーザーをグループ化した「ロール」という概念がない – MySQLで複数ユーザーに同一の権限セットを割り当てたい場合は、複数ユーザー にGRANT文を同じように実行する必要がある – MySQL 8.0からロールができる模様 https://yoku0825.blogspot.jp/2016/09/mysql-800role.html • (Oracleでいうところの)スキーマという概念がない – Oracleのスキーマ:あるユーザーが所有するすべてのオブジェクトを格納する論 理的な箱 – MySQLではデータベースをスキーマと呼ぶ場合もあるようだ
  12. 12. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 12 MySQLのアーキテクチャ • スキーマやオブジェクトの所有者という概念はない • データベースに接続する=デフォルトの名前空間の選択 テーブル データベース ユーザー 接続 データディレクトリ (datadir) テーブル ユーザー定義 mysqlデータベース
  13. 13. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 13 Oracle Databaseのアーキテクチャ • ユーザーと同名のスキーマ名が必ず存在し、そのスキーマに接続する • オブジェクトは所有者ユーザーのスキーマに存在 データベース ユーザー 接続 スキーマ (接続ユーザーが所有する)テーブル 1対1で対応 スキーマ (接続ユーザー以外のユーザーが所有する)テーブル
  14. 14. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 14 (参考)PostgreSQLのアーキテクチャ • オブジェクトはある特定のスキーマに格納する • オブジェクトの所有者とスキーマは独立した概念 – SCOTTユーザーのテーブルをHRスキーマに格納できる スキーマ テーブル スキーマ テーブル データベース ユーザー 接続 データベース クラスタ スキーマ テーブル スキーマ テーブル ユーザー定義
  15. 15. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 15Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. 領域管理の考え方が違う
  16. 16. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 16 MySQLの領域管理 • datadir → ディレクトリ(データベース) → ファイル(テーブル) データディレクトリ (datadir) <データベース名> [テーブル名].ibd 表領域 データファイル テーブルサイズの増加に応じて ファイルサイズが増加 テーブルサイズの増加に応じて ファイル内の占有領域サイズが増加 初期構成時点で事前に領域割り当て 表領域の空き領域不足時に拡張 • Oracleの領域管理 – 表領域(複数のデータファイルから構成) → セグメント(≒テーブル) テーブルとファイルが1対1で対応
  17. 17. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 17 I/O負荷の分散 考え方 Oracle Database MySQL ファイルを別々の ディスクに配置して I/O負荷の分散を図 る 表領域を複数のデータファイルか ら構成するようにして、 それぞれのデータファイルを別々 のディスクに配置する データベースのディレクトリを別 ディスクに配置し、 デフォルトの場所からシンボリッ クリンクを張る CREATE TABLEにDATA DIRECTORY句を指定して、デ フォルトとは異なるディスクに保 管する (MySQL 5.6以降) ファイルシステム以 下のレイヤーで複数 ディスクを束ねるこ とでI/O負荷の分散 を図る ASM(Oracleに同梱されるボ リュームマネージャ相当のソフト ウェア)を使用する OS標準およびサードパーティの ボリュームマネージャなどを使用 する
  18. 18. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 18Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. 恐怖の「SQLモード」
  19. 19. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 19 SQLモード • SQLモード(SQL_MODE)とは – SQL処理における以下の振る舞いを調整するシステム変数 – 1. サポートするSQL文法を調整 – 2. データチェック機構の動作を調整 • 自動調整 + OK • 自動調整 + 警告 • エラー • SQLモードの意義? – 過去バージョンのMySQL独自文法に従って記述されたSQLを実行可能に しつつ、標準ベースのSQLも実行可能にすること? – Oracle Databaseには類似のパラメータは存在しない (おそらく他のRDBMSも)
  20. 20. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 20 1. サポートするSQL文法を調整する例 • '||'で文字列連結できない → '||' は論理和演算(OR演算) – SQL_MODE='PIPES_AS_CONCAT'を設定すれば、文字列連結できる • 引用符(クォート文字)の扱いが違う mysql> SELECT 'A' || 'B'; +------------+ | 'A' || 'B' | +------------+ | 0 | +------------+ 1 row in set, 2 warnings (0.00 sec) mysql> show warnings; +---------+------+---------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------+ | Warning | 1292 | Truncated incorrect DOUBLE value: 'A' | | Warning | 1292 | Truncated incorrect DOUBLE value: 'B' | +---------+------+---------------------------------------+ 引用符 (クォート文字) MySQL Oracle Database MySQL (SQL_MODE=ANSI_QUOTE) シングルクォート(') 文字列リテラル 文字列リテラル ダブルクォート(") 文字列リテラル 識別子 バッククォート(`) 識別子 -
  21. 21. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 21 2. データチェック機構の動作を調整する例 mysql> SET SQL_MODE='STRICT_ALL_TABLES'; Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO testaid VALUES('2013-02-30'); ERROR 1292 (22007): Incorrect date value: '2013-02-30' for column 'd' at row 1 mysql> SHOW ERRORS; +-------+------+------------------------------------------------------------+ | Level | Code | Message | +-------+------+------------------------------------------------------------+ | Error | 1292 | Incorrect date value: '2013-02-30' for column 'd' at row 1 | +-------+------+------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> SET SQL_MODE=''; mysql> INSERT INTO testaid VALUES('2013-02-30'); Query OK, 1 row affected, 1 warning (0.00 sec) mysql> SHOW WARNINGS; +---------+------+----------------------------------------+ | Level | Code | Message | +---------+------+----------------------------------------+ | Warning | 1265 | Data truncated for column 'd' at row 1 | +---------+------+----------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT * FROM testaid; +------------+ | d | +------------+ | 0000-00-00 | +------------+ 1 row in set (0.00 sec) SQL_MODE 不正な日付の扱い (例: 2013-02-30) STRICT_ALL_TABLES エラー 指定なし(デフォルト) 警告 0000-00-00にデータを変更 エラー 警告
  22. 22. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 22 SQLモードの恐怖 • 正確には「SQLモードのデフォルト値の恐怖」 • 現場的にはデータチェック機構が緩いことに起因する不 正データ混入が怖い – ゼロの月やゼロの日 – など • とうとうMySQL 5.7GAでデフォルト値が大きく「改善」 – すみません、発表準備のときまでこのことを知りませんでし た・・・
  23. 23. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 23 SQLモードの分類 C) Strict Mode B) Combination Mode SQLモード設定値 説明 ORACLE TRADITIONAL 他 ALLOW_INVALID_DATES 日付の完全チェックを行わないようにする (例:'2004-04-31'を許す) NO_ZERO_IN_DATE 月または日が'0'の日付を警告扱いにする(*1) o NO_ZERO_DATE 日付'0000-00-00'を警告扱いにする(*1) o ERROR_FOR_DIVISION_BY_ZERO '0'の割り算を警告扱いにする(*1) o ANSI_QUOTES 引用符の扱いをANSI準拠にする o PIPES_AS_CONCAT '||'を論理和演算子(OR)ではなく、文字列連 結として扱う o IGNORE_SPACE 関数名と'('の間の空白を許す o NO_AUTO_CREATE_USER GRANT文実行時に該当ユーザーが存在しな い場合、自動的にユーザーを作成しない o o NO_ENGINE_SUBSTITUTION 使用するストレージエンジンをMyISAMに自 動的に置換しない o 他 SQLモード設定値をセットにして名前をつけたもの 構成するSQLモード設定値を列挙するのと同じ効果 データのチェック動作を強化し、警告をエラーにする A) 通常のSQLモード設定値 それぞれの設定項目に対応して、サポートするSQL文法と、データ チェック動作を変更する SQLモード設定値 説明 STRICT_ALL_TABLES Strict Modeを全テーブルに適用 STRICT_TRANS_TABLES Strict Modeをトランザクション対応テーブルにのみ適用 太字はMySQL 5.7GAでデフォルト採用 (*1) Strict Modeだとエラーとなるデータチェック動作
  24. 24. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 24Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. トランザクションログが2つある?
  25. 25. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 25 トランザクションログが2種類ある • トランザクションログとは? – データベースに適用された更新処理を記録しておくファ イル – プロセス障害からの復旧、ファイル消失・破損からの復 旧に使用される • バイナリログ – データベース更新時、DMLまたは行データが記録される – 基本的にステートメントベースのロギング (binlog_formatで変更可能) – レプリケーションと復旧時のロールフォワードに使用さ れる – ファイル順次生成 • InnoDBログ – InnoDBテーブル更新時、物理的な更新情報が記録され る – フィジオロジカルロギング – インスタンスクラッシュ時のクラッシュリカバリに使用 される – ローテーション書き込み mysqld <hostname>-bin. 000099 <hostname>-bin. 000001 ib_logfile0 ib_logfile1 :
  26. 26. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 26 トランザクションログの役割と、担うファイル 役割 説明 MySQL Oracle クラッシュ リカバリ インスタンスが異常終了した際に、次回起動時 にデータベースの整合性を回復する InnoDB ログファイル REDOログファイル (オンライン) メディア リカバリ ファイル消失・破損後によってバックアップを 戻す必要がでた場合に、 バックアップに適用されていない更新処理を(再 度)適用する(ロールフォワード) バイナリログ ファイル REDOログファイル (オンライン+ アーカイブ) 障害 00:00相当 の状態 更新 12:00相当 の状態 バイナリログ ファイル 00:00 12:0012:00 バイナリログファイル に記録された 更新系SQLを再実行 00:00 データの エクスポート 00:00時点の エクスポート データ データを インポート 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新 mysqldump mysqlbinlog メディアリカバリによるファイル破損への対処
  27. 27. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 27Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved. ナイーブなレプリケーション
  28. 28. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 28 レプリケーション mysqld(プライマリ) バイナリログ データ ファイル データ ファイル リレーログ mysqld(スレーブ) 更新系SQLを記録 更新系SQLを 読み取り、実行 Oracleインスタンス (プライマリ) オンライン REDOログ データ ファイル データ ファイル スタンバイ REDOログ Oracleインスタンス (フィジカルスタンバイ) ブロックへの更新 内容を記録 ブロックへの更新内容 を読み取り、適用 pull型 push型 MySQLのレプリケーション Oracleのレプリケーション(Data Guardフィジカルスタンバイ) SQL
  29. 29. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 29 レプリケーションの比較 項目 Oracle Database (Data Guardフィジカルスタンバイ) MySQL 更新同期の考え方 データブロックの更新内容を転送 し、プライマリDBと同じように データブロックを物理的に更新す る 更新系SQLそのもの(または列 データの変更)を転送し、スタン バイDBでSQLを再実行する 同期性 (プライマリDBのコ ミットと更新データ転 送の関係) スタンバイDBへの更新データ転 送が完了するまでコミットできな い構成(同期モード)で使用され るケースが多い。 (データの保護を重視することが多い ため。データ転送完了前にコミットで きる構成も可能) プライマリDBでのコミット可否 とスタンバイDBへのデータ転送 は非同期 (準同期レプリケーションではスタン バイDBへのデータ転送を待機) 待機系DBにおける 更新適用処理の パラレル化 自動的に有効 5.5以前 パラレル不可 5.6 限定的に可能 5.7 可能 使用可能なEdition Enterprise Edition 全Edition ※:MySQLレプリケーション類似の機能としてGolden Gateという別売製品もあります
  30. 30. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 30 MySQLレプリケーションの仕組みからくる特性 • 利用者が実行SQLがunsafeかsafeどうかに留意する必要がある – SQLベースのレプリケーション故の制限 – 意味的にunsafeであるにも関わらず、MySQL内部のチェックに引っかからない ケースもある筈で、データ保護の観点からはちょっと怖い気もする • プライマリDBはスタンバイDBのことをあまり気にしない – プライマリDBのコミット完了と更新データ転送に関係性がないため – データ保護をレプリケーションの第一目的と考えるOracle Databaseの感覚とは かなり異なる • 大量トランザクション実行時にスレーブの更新が遅れがち – パラレルで実行している更新処理を、スレーブでシリアル実行しているため • 大量更新はOracle Databaseでも辛い部分がありますが – MySQL 5.6から、スレーブでパラレル更新が実行可能に – MySQL 5.7では、パラレル更新がより効率的に • バイナリログにパラレル更新用お制御情報を追加することで実現(Thanks 山崎さん!) • 柔軟な構成が可能 – 一部のテーブルのみを同期する、一部のデータベースのみを同期するなど – (意味があるかどうかは別にして)稼働系と待機系で異なるストレージエンジンを使 用することすら可能! – Oracle DatabaseのDataGuardフィジカルスタンバイでは 原則的に稼働系と待機系で実行される更新処理および物理構造は同一 • データファイルにおけるブロック単位の変更を同期しているため • 反面、一部のテーブルのみを同期するなんてことはできない
  31. 31. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 31 [驚いたこと] replicate_do_dbの罠 • replicate_do_db: レプリケーション対象のデータベース を限定するパラメータ • 個人的に2つの罠にハマったので共有しておきます mysqld(プライマリ) mysqld(スレーブ) db1 db2 replicate_do_db=db1 db1 db2
  32. 32. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 32 [驚いたこと] replicate_do_dbの罠1 • 罠1 (初級編) – binlog_mode=statement、replicate_do_db=db1 – db1以外のデータベースの更新が同期される・・・ mysqld(プライマリ) mysqld(スレーブ) db1 db2 replicate_do_db=db1 db1 db2 INSERT INTO db2.tbl1 ...
  33. 33. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 33 [驚いたこと] replicate_do_dbの罠1 • 期待通り動作しない理由 – binlog_mode=statementでは、SQL文実行時のカレントデータ ベースで同期対象かどうかが判断されるため • SQL文で指定したオブジェクトのデータベース名ではない • binlog_mode=rowとすると、 SQL文で指定したオブジェクトの データベース名で同期対象かどうかが判断されるため、この問題を一 応回避できる(他にいろいろ面倒なルールはありますが・・・) mysqld(プライマリ) mysqld(スレーブ) db1 db2 replicate_do_db=db1 db1 db2 use db1; INSERT INTO db2.tbl1 ... use db1; INSERT INTO tbl1 ... binlog_mode =statement
  34. 34. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 34 [驚いたこと] replicate_do_dbの罠2 • 罠2 (上級編?) – binlog_mode=row、replicate_do_db=db1で、DDLが伝搬され たりされなかったりする mysqld(プライマリ) mysqld(スレーブ) db1 db2 replicate_do_db=db1 CREATE TABLE ... CREATE TABLE ... db1 db2 binlog_mode = row
  35. 35. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 35 [驚いたこと] replicate_do_dbの罠2 • 期待通り動作しない理由 – DDLはbinlog_mode=rowでもステートメントベースで実行 =「binlog_mode=statement相当」 → DDL実行時のカレントデータベースで同期対象かどうか判断 – カレントデータベースがdb1 → DDLが伝搬 カレントデータベースがdb1以外 → DDLが伝搬されず mysqld(プライマリ) mysqld(スレーブ) db1 replicate_do_db=db1 use db1; CREATE TABLE db1.t1 use db2; CREATE TABLE db1.t2 binlog_mode = row db1
  36. 36. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 36
  37. 37. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 37 (参考) Oracle Databaseとの対照表 1/2 # Oracle Database MySQL 説明 1 スキーマ データベース MySQLにおけるデータベースは、Oracleにおける永続表領域とス キーマをあわせたような特性を持つ。 すなわち、セグメント(オブ ジェクト)と物理ファイルとの対応関係を規定する物理的な役割と、 オブジェクトのコンテナという論理的な役割を併せ持つ 2 表領域 3 オブジェクト所有者 N/A MySQLのオブジェクトには所有者という概念はない 4 制御ファイル N/A 該当するファイルはない 5 SYSTEM表領域 mysql データベース ディクショナリ相当の情報(の一部)を表として格納するデータベー ス。SYSTEM表領域に似ている ユーザー情報を格納するmysql.userテーブルなどの権限関係のテーブ ルが格納される Oracle Databaseでディクショナリ表として管理される情報が、全て mysqlデータベース内の表で管理されるわけではない。たとえば、 テーブル定義は、*.FRMファイルで保持される 6 SYSTEM表領域 +UNDO表領域+永 続表領域 InnoDB テーブル スペース (InnoDBテーブルに関連する) Oracle Databaseでいうテーブルセ グメント、インデックスセグメント、テーブルに関連するディクショ ナリ情報、ロールバックセグメントが格納されるデータ領域 MySQLではSYSTEM表領域、UNDO表領域は独立した記憶領域として 存在しない ユーザー指定の永続表領域(USERSなど)を明示的に作成することは できない
  38. 38. Copyright © 2016 CO-Sol Inc. All Rights Reserved. 38 (参考) Oracle Databaseとの対照表 2/2 # Oracle Database MySQL 説明 1 一時表領域 tmpdir tmpdirシステム変数で指定されたディレクトリに作業ファイルが 作成される 2 オンラインREDOロ グ バイナリログ InnoDBログ バイナリログがメディアリカバリ(バックアップリストア後のリ カバリ)におけるロールフォワード、レプリケーションに使用さ れる InnoDBログがクラッシュリカバリに使用される 3 アーカイブREDOロ グ バイナリログ 古いバイナリログがアーカイブREDOログに相当する バイナリログはファイルを順次生成する(ローテーションしな い) 3 環境変数 ORACLE_SID --socketオプション (--socketオプションが事実上インスタンスの識別子になるが、 明示的に示されるものではないので、取扱いにくい印象) 4 V$ビュー DBA_ビュー INFORMATION_SC HEMA いくつかの診断情報が確認できるが、情報量は限定される 5 初期化パラメータ システム変数 (オプション) mysqldの動作を制御する。オプションファイル(my.cnf)や、 mysqld起動時のコマンドラインオプションなどで指定できる 初期化パラメータと同様、動的変更可否とスコープ(グローバル、 セッション)という概念が存在する 6 pfile my.cnf MySQLサーバ以外の製品の設定も記載できる 優先度の異なる複数my.cnfの設定がマージされる場合がある 7 spfile N/A 該当なし

×