PITR

どうも、69です。

ご無沙汰しております。
69は今日も生きていますよ！


掲題のとおりポイントインタイムリカバリについてです。
もう完全にPostgreSQLです。。。

まぁ、まずLAPP環境を整え、PHPからプログラミングを学んで
Javaに行き、Androidという流れを。。。ということで、お許しください。
いつになることか…


PostgreSQLでは3通りのバックアップがあります。
そのうちの1つがPITRです。

何がいいかって言うと

データベースを止めずにバックアップがとれる！
比較的短時間でバックアップがとれる！
リカバリがベースバックアップから障害発生までの間の任意の時間に戻せる！
もちろん最新の状態に戻すことも可能！

こんな感じかな？
でも、もちろん欠点はあります。

多少、手順が煩雑。。
メジャーバージョンの移行には適さない。。
WALログ・アーカイブログのサイズに気をつける。。

ぐらいかな？

で、今日言いたいことは


PITRなら人生をやり直せるって事！！！！


ただし、ベースバックアップの中に含まれてしまったらダメ！
ベースバックアップから最新の間だけね！

細かい手順とか用語とか、残りの2つのバックアップについては、また今度。

とりあえず、今日言いたいことは

PITRなら人生をやり直せるって事！！！！

僕もあの時に戻りたい。。。

おしまい。

プロ

どうも、69です。



今日？昨日？ライブを観に行って、帰りにタクシーを使いました。
フツーに乗ってフツーに走りだしました。


目的地までの半分くらい走ったところで、運転手の方は異変に気付きました。
僕が乗っていたタクシーを止めようと手を挙げている人がちらほら。。。

運転手の方はメーターを確認しました。
料金が表示されていませんでした。
気付いた時点でメーターを開始しました。
運転手の方は
「料金が半分くらいになっちゃうね。。。」
「料金表示のところに、あと何時間働くかが書いてあってわかりにくいんだよね。。。」
「ここに（ハンドルの横）に空車って書いてあるんだけど、読めないんだよね。。。」
と言いました。そして最後に

「ちょっと色付けてよ！」

と。まぁ、冗談だと思っていました。


そして、目的地に到着し、料金を払う時が来ました。
1880円（確か、そうだったはず）を要求されました。
1000円札2枚で2000円を払い、お釣りをもらおうと待っていました。

返ってきたのは

「じゃ、2000円で貰っちゃっていいかな？」

というお言葉でした。


ミスったのは運ちゃんなのに、そんなことほんとに言っちゃうんだ！
って思ってね、もうね、言葉にならないです。。。


自分も気をつけないと、そうなっちゃうな！っと勉強になりました。
ミスって、しょうがないじゃん、それでいいじゃん。って。

おしまい。

制約

どうも、69です。

今日はリレーショナル・データベースの知識についてです。


制約とはデータ内容の矛盾を防ぐ機能です。

SQLのようなデータベース言語は
アプリケーションとは無関係に、制約を格納できなくてはならない。
んだそうです。「コッドの12の法則」で提唱されているんですって。。

コッドの12の法則はhttp://androidid-69.blogspot.com/2011/07/12.htmlでチラッと触れましたが
ググるったほうが、良さそう。。。

で、制約は属性（列）に定義します。以下に代表的な制約を挙げます。

1．非ナル制約(NOT NULL)
→指定した属性(列)に値が入っていない状態じゃないことを保証
NULLでないことを保証

2．主キー制約(PRAIMARY KEY)
→テーブルの中でレコードを一意に識別する値
NULL値であってはいけない⇒非ナル制約を満たしている必要あり
テーブルの中で1つだけ指定できる
複数の属性(列)でPRAIMARY KEYを構成できる

テーブルの中にあるレコードを一意に識別する値が複数個の属性(列)ある場合
それらを候補キー(主キーの候補)と言います。
で、候補キーから主キーを選択し、それ以外の選択されなかったものを代替キート言います。

レコードを一意に識別できる候補キーがない場合
連番などの自然発生的でないキーを作成し、それを主キーとします。
これを人工キーと言います。

3．一意性制約(UNIQUE)
→テーブルの中の列、または列の組み合わせが一意であるを保証
列の中に重複する値が発生しないことを保証
主キー(PRAIMARY KEY)との違いは、
・NULL値を許可すること
・1つのテーブルに複数指定できる

4．外部キー(FOREIGN KEY)制約
→テーブル同士の関連付け
参照整合性制約を付加できる
→テーブルBのFOREIGN KEYに指定された属性(列)の値は
テーブルAの一意性のある属性(列)の値に存在するものでなければならないってこと


テーブルAの一意性のある属性(列)をテーブルBで参照するときに
テーブルB側の属性(列)はFOREIGN KEYとなります。

テーブルA側の属性は主キーであることが多いらしいですが、必須条件ではないそうです。
一意性があればいいんだそうです。


う～ん。たぶんですが…

あるテーブルで一意性のある属性(列)を
そのほかのテーブルで使用したいときに使用する

のかな？？

5．チェック制約(CHECK)
→属性(列)の値が、指定した条件を満たすものしか入らないことを保証


わからないことがありましたら、ググってください。
そして、コメントに書き込んでください！(笑)
僕がブログを作るんじゃない。みんなで、いいブログにしていきましょう！！(笑)

おしまし。

Oracle-2

どうも、69です。

昨日、前回OracleをLinux環境に入れよう！！と意気込んでいました。

が、グループ作ってユーザまで作りました。
で、肝心のOracleを解凍していたら


途中で/homeがいっぱいになってしまいました。。。

しかも、1/2の途中で。。。なので2/2も当然解凍できない。。。


で、解凍先を変えてみようとしたのですが
たぶん所有者・グループが違うからだと思うのですが、失敗しました。。。

というわけで、パーティションから区切り直しかな～なんて思う今日この頃。


あ、あとCentOSではOracleって入らないらしいんです。
でも、世の中いるんですよね～、すごい人が。
で、その方のを参考にしている訳で、あんまり公開できない…



おしまい。

Oracle

どうも、69です。

今Oracle11gR2をLinux（CentOS）に入れようとしてます。
てか、勉強中です。

DBマスターになります。


PostgreSQLとOracleとMySQLを押さえてSQL文をガリガリと。


そしたら、転職の時に「あなたは何できますか？」って言われても大丈夫！
まだ、転職は考えてないですがね。。。

あとは、将来のためにシェルスクリプトを。。。
って、このブログのタイトルと違う道に進み始めてる…

まぁ、適当な人間のブログだし！
明日には↑も撤回されてるかもだし！

おしまい。