Oracleデータベースのリカバリとリストアの概念が少し理解しずらかったので整理しておこうと思います。
基本的にはパソコンのOSなどにおけるリカバリ（復旧）／リストア（復元）と言葉的な概念は同じですが、実作業は異なるものだと別物と覚えたほうが良さそうです。
本日、「ORACLE MASTER Bronze DBA11g」を受験してきました。
結果は68%でギリギリで合格でした（^^;;
正直、試験終了時には落ちててもおかしくないなあという手応えだったので、運良く拾ったという感じでした。
Oracleの試験はピアソンVUEですが、以前は試験終了後に即合否がわかりましたが、今は受験後30後位にメールで送られてきてOracleのサイトにアクセスする事で合否が確認出来る形式になっています。そのメールが来るまでの間がなんとも気持ち悪かった・・・。
今回は何とか合格は出来ましたが、理解度はまだまだなので引き続き学習は必要です。
さて次は何受けようかな。
テーブルのデータを削除する方法として「DELETE」コマンドと「TRUNCATE TABLE」コマンドの2つがあります。
両者を使用する場合、どのような用途で使用するべきか違いについてまとめておきます。
|
1 |
DELETE FROM sample_table; |
|
1 |
TRUNCATE TABLE sample_table; |
データベースの資格と言えばオラクルが有名ですが、LINUXの資格であるLPICで有名なLPI-JAPANがOSS-DB技術者認定試験というものを実施しています。
オープンソースデータベース技術者のための技術者認定試験ということで年々受験者が増えているそうです。
ここでオープンソースデータベースなのだからMySQLなどの問題もでるのかと思ったらそうではなく、PostgreSQLがメインとなっています。
そのため、これではオープンソースデータベースではなくてPostgreSQLのための資格試験ではないかという批判もあるようです。
データベーススペシャリストとオラクル、OSS-DBとデータベースに関する有意な資格がみっつできたことは喜ばしいことかもしれません。
オラクルは高額すぎて会社で取らせて貰えなかったら手が出せない人もいるかもしれません。そういった場合にデータベーススペシャリストもそうですがOSS-DBも選択肢のひとつに入るでしょう。
OSS-DBはSilverとGoldにわかれていて難易度が違います。受験料も共に15000円とオラクルに比べれば低額となっています。
まだまだこれからという試験ではありますが、技術者としての腕を証明するためのひとつとして活用していきたいですね。
ちょっとした案件でデータベースというとMySQLをとりあえず使っておこうという人はそれなりにいたかと思いますが、いまはその状況が変わってきています。
MySQLのオリジナルコードの作者のひとりがMySQLのコードをフォークして新しいプロジェクトを立ち上げたからです。
MariaDBという新しいデータベースプロジェクトです。MySQLと互換性も高く機能の取り込みも早いとの話です。
GoogleもMySQLからMariaDBに乗り換えたという話が出てきています。
よく使われるLinuxディストリビューションのひとつであるCentOSの標準環境もMySQLからMariaDBに変わりました。バージョン7からです。
CentOSだけではなくFedoraなどもMariaDBを標準に採用しているということだそうです。このことからもわかるとおりにMySQLからMariaDBへの移行が進んでいます。
CentOSさえもMariaDBを標準で採用したことからもわかるとおりに、この流れは止まらないことでしょう。
もしも乗り換える際は当たり前の話ですがきちんと検証してから使っていきたいですね。
現代は顧客の情報や、企業の商品の情報など様々な情報がデーターベースに記録されています。
このデーターベースは、企業活動や社会活動の中で非常に大きな役割を果たしており、それなしでは今の情報化社会を営んでいくにあたり大きな支障をきたすことになります。
それゆえに、そのバックアップを取得し万が一の事態へ備えることは非常に重要なことになります。
データーベースのバックアップ方法は大きくコールドバックアップ(オフラインバックアップ)とオンラインバックアップの二種類に分けられる。
コールドバックアップとは、データーベースを停止(Shutdown)させて取得するバックアップのことであり、オンラインバックアップとはデーターベースを停止させない状態のまま取得するバックアップのことである。
コールドバックアップではデーターベースを停止させるため、その間データーベースへのアクセスが出来なくなるというデメリットはあるが、データーベースを停止させ、その時の状態を取得することで、障害時にはこのバックアップのみ使用し、簡単迅速にリカバリできるというメリットがあります。
これに対してオンラインバックアップではデーターベースを停止させないため、サービスを運用状態でバックアップが取れるが、障害時はバックアップデータに加えてアーカイブログが必要となるなど、リカバリに手間と時間がかかる問題があります。
どちらも一長一短ですが、上手く目的に応じて両方を組み合わせるなど適切な方法を使用していきたいものです。
少しIT関連に詳しい人なら不思議に思うことがありませんか？
データーベースに対して同時に書き込むことがあってもなぜデーターは正しく処理されるのか。あるいは同時に書き込もうとした場合に書き込みトランザクションはなぜエラーにならないのだろうかと。
OracleやMS SQL Serverなどのデーターベース管理システムでは、ある処理がデーターベースに書き込み中に他の処理がデーターベースに書き込もうとすると、排他制御と呼ばれる仕組みが働いて書き込めないようになっています。
このことにより、同時に複数のトランザクションがデーターベースの更新を行うことでデーターが壊れてしまったりすることを防いでいます。
その仕組みは大まかに以下の概要となります。
基本的にデータベース管理システムでは上記の様な方法で、複数トランザクションからの同時実行を制御しています。
PostgreSQLの大きな特徴として追記型のアーキテクチャであることです。このことによりデータが更新される度に使われないタプル（tuple）が蓄積されていきます。
PostgreSQLに必要な保守作業は、この使用されることのないタブルを解放し利用できる領域にすることが必須となっています。
この作業を行うのがVACUUMコマンドです。
VACUUMを実行するとデータベースのパフォーマンスを向上させることができます。
VACUUMには、VACUUM FULLと標準VACUUMがあります。
VACUUM FULLは、システムへの負荷が大きく作業に長時間を要します。
膨大な量のデータ削除を行った時や利用可能なディスク容量が急迫した等の緊急時以外は、VACUUM FULLは行うべきではありません。
標準VACUUMを定期的に行っていいれば、VACUUM FULLを実行する必要性が発生する頻度を低減させることができます。
また、なんとなくVACUUMを行うのではなく、pgAdminなどを使用してデッドタプル（不要領域）を確認してうえで実行することが重要です。
PostgreSQL8.1以降では、autovacuumが実装されていますのでメンテナンスにかかる負荷も低減されています。
PostgreSQL独自のSQLコマンドとしてCOPYコマンドが実装されています。
これはサーバ上にあるCSVファイルからある表に、一括してデータを流し込むこ操作を行うことの出来るコマンドとなっています。
コマンドは通常のSQLと同様にpsql上から発行できます。
表の全列にデータを流し込む場合には、以下の書式になります。
|
1 |
% COPY 表名 FROM 'CSVファイルのフルパス' WITH CSV; |
insert分などと同様に、表の一部の列にだけデータを流し込むことも可能です。
その場合のSQLの記述方法は以下となります。
|
1 |
% COPY 表名(列名1,列名2,…) FROM 'CSVファイルのフルパス' WITH CSV; |
また、サーバ側にCSVファイルがない場合、psqlの標準入力からCSV形式でデータを入力することも可能です。その場合には以下の書式となります。
|
1 2 3 |
% COPY 表名 FROM STDIN WITH CSV; % COPY 表名(列名1,列名2,…) FROM STDIN WITH CSV; |
PostgreSQLCOPYコマンドはデータ一括登録時時に便利なので覚えておくのも良いかもしれません。
PostgreSQLのバージョンは「9.1.14」の様に２つのピリオドに区切られた３つの数字で表記されています。
左から２つは、メジャーバージョンを表し、最後の１つはマイナーバージョンを表しています。
例えば、9.1.14なら、メジャーバージョンが9.1、マイナーバージョンが14となります。
メジャーバージョンアップは１年毎、マイナーバージョンアップは、年に３回～５回程度実施されます。
このバージョンをアップすることを維持管理と呼び、2015年1月27日現在で維持管理の対象となっているのは、9.4.0、9.3.5、9.2.9、9.1.14、9.0.18となります。
左端が8の8.4.22以前のものは、ダウンロードができます（available）が、維持管理の対象外（No longer supported）であり、これ以降はバージョンのアップは行われません。
維持管理対象外のバージョンは、「EOL’d releases」とも呼ばれています。EOLは「End-of-life」の略です。
マイナーバージョンアップは、バイナリ変更だけで対応できますが、メジャーバージョンアップでは、データファイルの移行の必要があるので、メジャーアップデート作業はアップデート計画に沿って、慎重に（シュミュレーション・予行演習など）行うことが大切となります。
