オンラインバックアップ
??????
また、オンラインバックアップを使って、最新かつ整合性の取れたデータファイルをバックアップする良い方法(一般的なセオリー)なんかがありましたら、教えていただきたいです。
Takahide Nojima
dam...@yahoo.co.jp (??????) writes:
> Oracleのオンラインバックアップにおいて、データファイルをバックアップ後に、発生したデータ更新処理(commit済み)は、その取得したデータファイルで復元することはできないのですか。
> また、オンラインバックアップを使って、最新かつ整合性の取れたデータファイルをバックアップする良い方法(一般的なセオリー)なんかがありましたら、教えていただきたいです。
Oracleは知りませんが、 DBなら所謂
・duplicationとか
・スナップショットとか、
いう機能が該当するような...
また、Oracle以外の製品でも同様の問題を回避できるファイルシステム構築用の
商用ソフトがあり、
・「RAIDの様に２つのディスクで通常運用し、バックアップする直前で
いきなり片方を外してバックアップし、バックアップ終了後は
RAIDと同様にバックアップ中の差分が自動で書き戻されて元の運
用状態に戻る」とか
も見たことがあります。商品名なんだっけなー？
Yasushi Shinjo
In article <m3k74tz...@nightmare.hm.taito.co.jp>
Takahide Nojima <noj...@taito.co.jp> writes:
> また、Oracle以外の製品でも同様の問題を回避できるファイルシステム構築用の
> 商用ソフトがあり、
ファイル・システム・レベルのスナップショットがとれても、アプ
リケーション・レベル（データベース含む）の状態が完全に復元で
きるわけではないですよね。ファイルにこれから書こうと思ってま
だ書いてなかったとか。
In article <55eeb400.03121...@posting.google.com>
dam...@yahoo.co.jp (??????) writes:
> Oracleのオンラインバックアップにおいて、データファイルをバッ
> クアップ後に、発生したデータ更新処理(commit済み)は、その取
> 得したデータファイルで復元することはできないのですか。
ファイル・システムのレベルとデータベースのレベルを混ぜても、
突き詰めて考えると最後は意味がないんじゃないかなあ。
同様に、ある瞬間のディスクの内容をコピーたとしても、それが
ファイル・システム・レベルで整合性が取れている保証もありません。
> また、オンラインバックアップを使って、最新かつ整合性の取れ
> たデータファイルをバックアップする良い方法(一般的なセオリー)
> なんかがありましたら、教えていただきたいです。
整合性は、トランザクションのレベルで考えるのでしょうね。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Takahide Nojima
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 新城＠筑波大学情報です。こんにちは。
>
> In article <m3k74tz...@nightmare.hm.taito.co.jp>
> Takahide Nojima <noj...@taito.co.jp> writes:
> > また、Oracle以外の製品でも同様の問題を回避できるファイルシステム構築用の
> > 商用ソフトがあり、
>
> ファイル・システム・レベルのスナップショットがとれても、アプ
> リケーション・レベル（データベース含む）の状態が完全に復元で
> きるわけではないですよね。ファイルにこれから書こうと思ってま
> だ書いてなかったとか。
しまった。そのとおりです。というわけでこの手の製品はDBのバックアップには
使えないと。確かに大変ですなー
Shinji KONO
In article <m3brq5y...@nightmare.hm.taito.co.jp>, Takahide Nojima <noj...@taito.co.jp> writes
> しまった。そのとおりです。というわけでこの手の製品はDBのバックアップには
> 使えないと。確かに大変ですなー
この手の製品ってファイルシステムのバックアップで、DBのバック
アップってのは、それと直交したものですよね。
でも、ファイルシステムのバックアップからでも最低限の所まで戻
るのがDBの役目だと思うけど... 逆に、テープやリムーバブルディ
スクに取れるようにするのがDB のバックアップなわけだよね。
結局、リーダブルなフォーマットじゃないとバックアップに使えない
みたいなところもあるからなぁ。
Database ( commit, log, log truncate, recovery)
は「現在動いている最中のリカバリ」で「ハードディスクそのもの」
とか、ビルそのもの」が消えるのには対処してないんだよな。で、
Database ----backup----> flat text,CSV,XML
みたいなのを定期的に変換して、それをバックアップツールで
バックアップするってわけだ。
でも、なんか、flat textのサーチが十分速いんで、最近は、
Database なんかいらないんじゃないかって感じですね。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
河野真治 @ 琉球大学工学部情報工学科,
Yasushi Shinjo
In article <3989274...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
> でも、ファイルシステムのバックアップからでも最低限の所まで戻
> るのがDBの役目だと思うけど...
たしかに。あの記事書いたあと、commit したものはファイルに残っ
ているのだから、ファイルから commit したものは復元できるのは
（最後の一言をのぞいて）できるだろうと思いました。
逆に、commitしてないけどファイルに書いたというのがあった時は、
まあ、大丈夫なんですよね。
問題は、バックアップが瞬時に終るかどうかかな。時間差が出てく
るとアウトです。スナップショットをとった時刻そのものは、意味
がないとして。瞬時は、カーネルのファイル・システムのレベルで
も難しいんですけど。sync しても、別のプロセスの creat が先に
端って、その後 sync からリターンするかもしれないから。結局、
ハードディスク・レベルの瞬時ミラーは、fsck で落ちるかも。
> Database ----backup----> flat text,CSV,XML
> みたいなのを定期的に変換して、それをバックアップツールで
> バックアップするってわけだ。
こんな層があったとします。
------------
データベース
------------
ファイル
------------
ディスク
------------
その時、
・上位レベルでバックアップとれば、下の方は不要。
・下のレベルでのバックアップは、上の代りにはならない。
・でも、データベースなら、ファイルのバックアップでもなんとか
なるはず
ということですか。
CyberKnight Blade
:
>> > また、Oracle以外の製品でも同様の問題を回避できるファイルシステム構築用
>の
>> > 商用ソフトがあり、
>>
>> ファイル・システム・レベルのスナップショットがとれても、アプ
>> リケーション・レベル（データベース含む）の状態が完全に復元で
>> きるわけではないですよね。ファイルにこれから書こうと思ってま
>> だ書いてなかったとか。
>
>しまった。そのとおりです。というわけでこの手の製品はDBのバックアップには
>使えないと。確かに大変ですなー
昔触っていた時期のOracleのオンラインバックアップは、あんまり
大した仕組みをしていなかったと思います。
Oracleのコマンドを実行し、
メインのデータベースファイルへの新規の更新をすべて停止させ、
以降のトランザクションデータを
redologファイルだったか、そっちに以降の更新を書き込みます。
で、メインのデータベースファイルは、一般ファイル上にあるなら
tarコマンドでもなんでもOS側のコマンドでバックアップ可能。
また、通常、メインのデータベースファイル領域とredolog領域は
別のパーティション（通常別のDISK）に分けるから
メインのデータベース領域のバックアップは、
DISKシステム側（SAN、NASその他）のスナップショット機能で
バックアップを取ればかなり速く終わるはず。
で、後から、スナップショットで取ったバックアップから、
最終的なバックアップメディア（DLTなどのテープメディア）などに
バックアップを行う。
なんでこうするかと言うと、大規模なシステムでは更新も頻繁で
redologがでかくなってしまい、
複数のredologファイルを再利用する仕組みだと昔の更新ログが上書きされて
最新の状態に戻せなくなるかもしれないからです。
パフォーマンスその他にも影響が出るかもしれないので、
オンラインバックアップによりメインのデータベース自体の更新を止める時間を
最短にする為
DISKシステム側のスナップショット利用によるDISKtoDISKのバックアップは、
意味があります。
-
<<-= Team CyberKnights. (First) 4bl...@cyberknights.net =->>
Shinji KONO
In article <YAS.03De...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> こんな層があったとします。
> データベース
> ファイル
> ディスク
これって「層」じゃないですよね。直交した概念なはず...
例えば、 NFS は複数のディスクにまたがてっいるし、
一つのディスクに複数のデータベースをおけるし...
> その時、
> ・上位レベルでバックアップとれば、下の方は不要。
> ・下のレベルでのバックアップは、上の代りにはならない。
> ・でも、データベースなら、ファイルのバックアップでもなんとか
> なるはず
> ということですか。
直交していればそうはならないんですよね。
(わかりずらいよね... まったく...)
Yasushi Shinjo
In article <3fe3b5b0$0$11232$44c9...@news3.asahi-net.or.jp>
CyberKnight Blade <5bl...@cyberknights.net> writes:
> Oracleのコマンドを実行し、
> メインのデータベースファイルへの新規の更新をすべて停止させ、
> 以降のトランザクションデータを
> redologファイルだったか、そっちに以降の更新を書き込みます。
>
> で、メインのデータベースファイルは、一般ファイル上にあるなら
> tarコマンドでもなんでもOS側のコマンドでバックアップ可能。
...
なるほど。バックアップ用に特殊な仕組みが含まれている、たとえ
ば、前回バックアップしたものは今回は取らないようなものが入っ
ているのかと思っていたのですけれど。
> パフォーマンスその他にも影響が出るかもしれないので、
> オンラインバックアップによりメインのデータベース自体の更新を止める時間を
> 最短にする為
> DISKシステム側のスナップショット利用によるDISKtoDISKのバックアップは、
> 意味があります。
Oracle って、ＯＳのファイル・システムは使わないで直接 raw
device をたたくというのが普通かと思っていたのですが、
ファイル・システムの方が普通なんでしょうか。
DISKtoDISKのバックアップならＯＳは関係ないのかもしれません。
書込みが行われていない領域なら、単に tar でなくて dd にすれ
ば、ファイル・システムを使った時と同じ手順でもいいんでしょうけど。
In article <3989276...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > データベース
> > ファイル
> > ディスク
> これって「層」じゃないですよね。直交した概念なはず...
> 例えば、 NFS は複数のディスクにまたがてっいるし、
> 一つのディスクに複数のデータベースをおけるし...
層は層でいいんじゃないかなあ。TCP/IP だって、同じ IP 層を使
いながら複数の TCP のコネクションはれるし、１つのコネクショ
ンでも別のルータ通ることもあります。
ものによっては、データベースの上のアプリケーション層まで何と
かする必要もあるんでしょうね。
??????
> メインのデータベースファイルへの新規の更新をすべて停止させ、
> 以降のトランザクションデータを
> redologファイルだったか、そっちに以降の更新を書き込みます。
全て停止させてる方法をとれば、バックアップ中に、データファイルへの書き込みは発生しない為、整合性は保たれますね。しかし、REDOログファイルは、相変わらずバックアップ中に書き込みが発生してしまい、やはり、バックアップ処理における整合性は保たれないと思いますが...。
CyberKnight Blade
:
>全て停止させてる方法をとれば、バックアップ中に、データファイルへの書き込み
>は発生しない為、整合性は保たれますね。しかし、REDOログファイルは、相変わら
>ずバックアップ中に書き込みが発生してしまい、やはり、バックアップ処理におけ
>る整合性は保たれないと思いますが...。
オンラインバックアップなのだから
トランザクションの更新処理を止められないのはおわかりでしょう？
OracleとしてDBの整合性の取れたバックアップを、トランザクションの
動いている間に取るにはこのオンラインバックアップしかなく、
これを利用して世の稼働中のOracleのバックアップは行われているのだから
信用してもいいんじゃないですか。
Networkerとか日立のなんとかいうシステムで行うバックアップでも
基本はこれだし。
以降の更新処理はredoログを持ってくればメインのデータファイルは最新の
状況までロールフォワードできるし。
別にOracleでバックアップに限らなくてもcomitt前のトランザクションも
ログに記録されていて障害発生時にロールバック/ロールフォワードを
行えるようになっていますよね。
レギュラーファイルの一般的なバックアップでもフルバックアップと
差分バックアップを組み合わせて行うのが基本なわけですから
Oracleのオンラインバックアップもフルと差分（redoログ相当？）で
最新に近い状態（comitt完）まで復旧できると思うのですけどね。
ちなみにredoログファイルのバックアップを行う前に、
新しいredoログに切り替えないとredoログが更新中でDBとして不整合が
起きるはず。
なんらかのタイミングで更新を止めないと整合性を保ったままで
バックアップはできない。
Shinji KONO
In article <3fe6f69a$0$11073$44c9...@news3.asahi-net.or.jp>, CyberKnight Blade <5bl...@cyberknights.net> writes
> なんらかのタイミングで更新を止めないと整合性を保ったままで
> バックアップはできない。
これができるってのが、グレイの論文で、はるか昔の話になるんだよな...
もともとトランザクションってのは、すべて整列されているわけだ
から、その整列順の特定の時点でバックアップを取れば、更新しな
がらバックアップは可能です。
> Oracleのオンラインバックアップもフルと差分（redoログ相当？）で
> 最新に近い状態（comitt完）まで復旧できると思うのですけどね。
できるのと実装されているのとは別だけどさ。
??????
> OracleとしてDBの整合性の取れたバックアップを、トランザクションの
> 動いている間に取るにはこのオンラインバックアップしかなく、
> これを利用して世の稼働中のOracleのバックアップは行われているのだから
> 信用してもいいんじゃないですか。
> 別にOracleでバックアップに限らなくてもcomitt前のトランザクションも
> ログに記録されていて障害発生時にロールバック/ロールフォワードを
> 行えるようになっていますよね。
Oracleでは、commitしない限り、SGA内(つまりメモリ上)での記憶に留まり、
ログファイル(ディスク)には書き込まれていないと思うのですが。
つまり、commit前のトランザクションは、インスタンスが落ちれば、
そのデータは、消えてなくなります。
> レギュラーファイルの一般的なバックアップでもフルバックアップと
> 差分バックアップを組み合わせて行うのが基本なわけですから
> Oracleのオンラインバックアップもフルと差分（redoログ相当？）で
> 最新に近い状態（comitt完）まで復旧できると思うのですけどね。
あくまで、最新に近い状態ですよね。ユーザ側からすると、厳密に、
どの時点あるいは何時まで回復できるのか知りたいと思うのですが...。
「曖昧では困ります。」(←というか、私がお客さんから言われてます。´Д｀)
> ちなみにredoログファイルのバックアップを行う前に、
> 新しいredoログに切り替えないとredoログが更新中でDBとして不整合が
> 起きるはず。
この場合、新しいredoログファイルはバックアップ対象ではないのですよね。
もし、バックアップ対象としてDB回復にも使用するなら、同様の不整合が
起こりますよね。
つまり、復旧可能なのは、切り替える前のredoログまでで、新しいredoログ
ファイルに書き込まれたトランザクションに関しては復旧不可能でよろしいでしょうか。
Iwao Watanabe
> ログファイル(ディスク)には書き込まれていないと思うのですが。
> つまり、commit前のトランザクションは、インスタンスが落ちれば、
> そのデータは、消えてなくなります。
業務システムなら、頻繁にcommitするものなので
たいてい数分くらい前までには戻りませんかね。
> > レギュラーファイルの一般的なバックアップでもフルバックアップと
> > 差分バックアップを組み合わせて行うのが基本なわけですから
> > Oracleのオンラインバックアップもフルと差分（redoログ相当？）で
> > 最新に近い状態（comitt完）まで復旧できると思うのですけどね。
> あくまで、最新に近い状態ですよね。ユーザ側からすると、厳密に、
> どの時点あるいは何時まで回復できるのか知りたいと思うのですが...。
> 「曖昧では困ります。」(←というか、私がお客さんから言われてます。´Д｀)
時間くらいはツールが出してくれたような気がしましたが，
（最近は戻す機会がないので忘れました）
復旧後、ログを記録しているテーブルに格納されているデータの
時間を確認してみればわかるのではないでしょうか。
ログなら時間も記録するのが普通でしょう？
ここでいうログは、REDOログファイルではなく、
アプリケーションレベルで記録しているログのことです。
> > ちなみにredoログファイルのバックアップを行う前に、
> > 新しいredoログに切り替えないとredoログが更新中でDBとして不整合が
> > 起きるはず。
> この場合、新しいredoログファイルはバックアップ対象ではないのですよね。
> もし、バックアップ対象としてDB回復にも使用するなら、同様の不整合が
> 起こりますよね。
> つまり、復旧可能なのは、切り替える前のredoログまでで、新しいredoログ
> ファイルに書き込まれたトランザクションに関しては復旧不可能でよろしいでしょうか。
REDOログファイルは追記方式なので，
稼動中にコピーしても不整合は生じないものだと認識しています。
上書きの切れ目は復旧ツールが自動認識してくれます。
それよりも問題なのは、テーブルスペース構成を変更したときに、
オフラインバックアップをし忘れると
REDOログのアーカイブがまったく役に立たないということです。
少なくとも私の知っている Oracle8iまでは。