Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード

2018-03-31

「Oracleの基本 〜データベース入門から設計/運用の初歩まで」の紹介

株式会社コーソルの 渡部さんOracle ACE)から献本いただいた「Oracleの基本 〜データベース入門から設計/運用の初歩まで」の紹介です。

一言で言うと新卒研修でデータベースの教科書として最適な本だと思います。

渡部さんとは JPOUG などのコミュニティ活動で以前から交流があり、コーソル社の社内勉強会にも何度かお邪魔したこともあります。Oracle 関連のイベントにお手伝いに来られた新卒ホヤホヤの方と挨拶したと思ったら数年後には第一線の現場で一緒に仕事させていただいたりしていましたが、ITの知識がなかった新卒や中途入社の方が数年後には一流のDBエンジニアとして第一線の現場やイベントの発表などで活躍されていて、データベース*1を勉強するには最もよい会社の一つだと思っていました。そのコーソル社のエンジニア育成で培われたノウハウが詰まった一冊だと思います。

敢えてアーキテクチャの説明を必要最低限に抑えて、Oracle Database をインストールして使いながら一通りの機能を使いながらウォークスルーする構成になっていて、コーソル社の育成の現場で培われたノウハウが詰まっていることが感じとれます。

初心者が資格取得から始めると暗記科目のようになってしまい、業務で一通り触れてからとなると1年以上はかかってしまったりしますが、本書は初心者が Oracle Database を最初に学ぶ上での高速道路になると思います。

また、ただの機能説明だけではなく著者陣の経験から得られたハマりポイントやなぜそうするかが散りばめられており、初心者ではなくても気づきがあるのではないかと思います。



オススメの読み方

Oracle Database を使ったことがない初心者の方が手を動かしながら通読するのがオススメです。ORACLE MASTER 取得や DB エンジニアを目指されているか方もまずはこの本を Oracle Database を使いながら通読するのが一番の近道ではないかと思います。


対象読者


一部引用

  • はじめに(P.3-4)

そこで,本書はOracle独自の用語の使用を最小限にとどめ,次の2点を考えながら執筆しました。

これらの解説ノウハウは,弊社コーソルの新人教育で培われたものです。コーソルの新人教育には,約2週間という短い期間で多くの新卒エンジニアORACLE MASTER Bronze DBAに合格させているという実績があります。さらに最近では,IT 未経験の新人エンジニアが,入社から2年半で,ORACLE MASTER Platinum(2日間の実技試験により認定されるORACLE MASTERの最上位資格)を取得するような例も出てきています。本書には,コーソルの新人エンジニアの生の声を反映させ,ノウハウを惜しみなく注ぎ込みました。

Oracleの基本 ?データベース入門から設計/運用の初歩まで:書籍案内|技術評論社
  • おわりに(P.353)

入門書という位置づけから、本書では、機能や使用方法に重点をおいて説明しました。よって、アーキテクチャについての説明を割愛しているところがあります。しかし、ひととおり、 Oracle を使えるようになったら、アーキテクチャにも目を向けてみてください。エンジニアであれば、「ソフトウェアがどうやって動いているか」ということに興味を持つのは自然なことですし、なにより、アーキテクチャを知っているかどうかで、理解度スキルの伸びに大きな差が出てきます。


目次

はじめに
本書について
第1章 データベースを知る
1.1 なぜデータベースは必要なのか
1.2 リレーショナルデータベースの基礎
本書の構成
第2章 Oracleを使ってみる
2.1 データベースを構築する
2.2 データベースに接続する
2.3 データベースを起動/停止する
2.4 学習用ユーザーを作成する
2.5 テーブルとデータ操作の基本
第3章 より高度なデータ操作を学ぶ
3.1 データを複雑な条件で検索する
3.2 データを加工/集計する
3.3 NULLとIS NULL条件
3.4 SELECT文とSELECT文を組み合わせる
3.5 テーブルを結合する
3.6 データの表示画面にこだわる
3.7 トランザクションでデータを安全に更新する
第4章 データをより高速に/安全に扱うしくみ
4.1 検索処理を高速化するインデックス
4.2 SELECT文をシンプルにまとめるビュー
4.3 不正なデータの混入を防ぐ制約
4.4 連番を振り出すシーケンス
4.5 セキュリティ機構の基礎となるユーザー機能
4.6 ユーザー権限を制御する
第5章 テーブル設計の基本を知る
5.1 テーブル設計とは
5.2 第1ステップ‐概念設計
5.3 第2ステップ‐論理設計
5.4 第3ステップ‐物理設計
第6章 データベース運用/管理のポイントを押さえる
6.1 データベースにおける運用/管理の重要性
6.2 バックアップを取ってデータを守る
6.3 データベースのメンテナンス
6.4 データベースを監視する
6.5 ネットワーク環境/本番環境でOracleに接続する
6.6 トラブルに立ち向かうためには
おわりに
索引
著者略歴
監修者略歴

*1データベースを勉強するなら Oracle Database から入るのがオススメです

2018-03-25

MySQL のストレージエンジンとのインタフェース

どの当たりのコードか当たりをつけ中。


  • Interaction of the Core Modules
    • Figure 1-1. High-level view of MySQL modules

f:id:yohei-a:20180325184159p:image:w360

ABSTRACTED STORAGE ENGINE INTERFACE (TABLE HANDLER)

This module is actually an abstract class named handler and a structure called a handlerton. The handlerton structure was added in version 5.1 for plug-in integration. It provides a standardized interface to perform low-level storage and retrieval operations.

The table hander is defined in sql/handler.h and partially implemented in sql/handler.cc. The derived specific storage engine classes will have to implement all the pure virtual methods of this class. It will be discussed in greater detail in Chapter 9.

This module was introduced in version 3.23 to facilitate the integration of Berkeley DB tables. This move had far-reaching consequences: now a variety of low-level storage engines could be put underneath MySQL with a fair amount of ease. The code was further refined during the integration of InnoDB. The future of the module will largely depend on what new storage engines will be integrated into MySQL, and on the way the existing ones will change. For example, sometimes a new feature in some underlying storage engine may require an addition to the abstracted interface to make it available to the higher-level modules.

Shared Aspects of Architecture

While there is a great degree of freedom in the implementation of a storage engine, all storage engines must integrate with the main MySQL server code. As a result they have a few things in common. Aside from having to support the basic concepts of tables residing in a database, records, columns, keys, read and write operations, and other aspects stipulated by the storage engine interface requirements, each storage engine also inherits the features and properties from the core table manipulation code. In other words, they get some functionality and architecture regardless of whether they need it.

Regardless of the storage engine, all tables have one .frm file per table containing the table definition with the column names, their types and sizes, key information, and other table properties. A .frm file in essence gathers and stores the information from CREATE TABLE. Up until version 5.1 the filename was always the same as the name of the table, and it resided in a directory corresponding to the database name. Version 5.1 introduced a change. The table and database name are now encoded in build_ table_filename( ) in sql/sql_table.cc. Code reads and parses the files using openfrm( ) from sql/table.cc, and writes to them using create_frm( ) from the same source file.

Regardless of the storage engine, the server reads the table definition from the .frm file, and stores it in what is called a table cache. This way, the next time the table needs to be accessed, the server does not have to reread and reparse the .frm file, but rather can use the cached information.

MySQL server utilizes the mechanism of table locking. Thus, each storage engine can either take advantage of this feature, or politely ask the table lock manager to always grant a write lock, which bypasses the core code table locking. In that case, the storage engine itself becomes responsible for ensuring consistency during concurrent access.

2018-03-24

Oracle Database で mutex を意図的に発生させる

Oracle Database で意図時に mutex(以下は"cursor: pin S") を発生させる。


以下のPL/SQLコードを同時多重実行する。

begin
for i in 1..1000000
loop
   execute immediate 'select 1 from dual where 1=2';
end loop;
end;
/

とかで発生状況をモニタリングする。

SQL> @snapper ash 60 1 user=sys

2018-03-21

Linux で CPU のマイクロコードのバージョンは /proc/cpuinfo で確認できる

LinuxCPU のマイクロコードのバージョンは /proc/cpuinfo で確認できる

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz
stepping	: 2
microcode	: 0x3b ★
cpu MHz		: 2899.843
cache size	: 25600 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single kaiser fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs		: cpu_meltdown spectre_v1 spectre_v2 ★
bogomips	: 5800.19
clflush size	: 64
cache_alignment	: 64
address sizes	: 46 bits physical, 48 bits virtual
power management:

参考

2018-03-16

Aurora Postgres で track_activity_query_size を変更して pg_stat_activity.query に記録されるクエリの長さを拡張する

設定変更

  • パラメーターグループを作成する
    • パラメータグループファミリー: aurora-postgresql9.6
    • タイプ: DB Parameter Group
    • グループ名: custom.aurora-postgresql9.6 (任意)
    • 説明: Custom parameter group for aurora-postgresql9.6(任意)
  • track_activity_query_size を 102400 に変更する
    • 作成したDBパラメーターグループ "custom.aurora-postgresql9.6" の track_activity_query_size を 102400(最大値) に変更する。
  • 作成したDBパラメーターグループを関連付ける
    • Aurora Postgres インスタンスDB パラメータグループを作成したパラメーターグループ "custom.aurora-postgresql9.6" に変更する。
  • Aurora Postgres インスタンスを再起動する
    • DBインスタンスDBパラメーターグループの表示が "aurora-postgres96-custom (再起動の保留中)" のように "再起動の保留中" と表示されたら、DBインスタンスを再起動する。

確認

  • track_activity_query_size の値を確認する。
aurora-postgres-r42xl awsuser 05:37 => show track_activity_query_size;
 track_activity_query_size
---------------------------
 102400
(1 row)

Time: 12.975 ms
  • 1024バイトを超えるクエリを実行してみて、pg_stat_activity.query で確認する。
select datid,
	datname,
	pid,
	usesysid,
	usename,
	application_name,
	client_addr,
	client_hostname,
	client_port,
	backend_start,
	xact_start,
	query_start,
	state_change,
	wait_event_type,
	wait_event,
	state,
	backend_xid,
	backend_xmin,
	query 
	from pg_stat_activity
union
select datid,
	datname,
	pid,
	usesysid,
	usename,
	application_name,
	client_addr,
	client_hostname,
	client_port,
	backend_start,
	xact_start,
	query_start,
	state_change,
	wait_event_type,
	wait_event,
	state,
	backend_xid,
	backend_xmin,
	query 
	from pg_stat_activity
union
(続く)
;
  • 上のクエリを実行する。

f:id:yohei-a:20180317051641p:image:w640

  • pg_stat_activity.query が 1024 バイトを超えて 5852 バイトまで表示されている。

f:id:yohei-a:20180317051649p:image:w640


補足

  • デフォルトのパラメーターグループの設定では以下の通り1023バイトまでしか表示されない。

f:id:yohei-a:20180317053507p:image:w640