バックアップファイルの復元に時間がかかる

質問

以下のコマンドを入力してSQLファイルを作成します。
mysqldump --databases DB名 > "保存先.sql" -u root
処理が完了するとSQLファイルが作成されており、
そのファイルを復元するのですが、処理に時間がかかってしまいます。
復元は以下のコマンドです。
mysql DB名 < "保存先.sql" -u root
復元処理は行われているのですが、2時間経過しても数万件の復元しかできていません。
データはデータベース全体で２００万件程度です。
バックアップの処理は２０分もかからない時間で完了するのに、復元だけがこんなに時間がかかるものなのでしょうか？
環境はOSがwindowsXP pro
MySQL 4.0.26です。
その他はapache2.0.59とphp5.1.6です。
宜しくお願いします。

回答No.4

qaz_qwerty_me

解決して良かったです ^ ^

> windowsOSのためバッチファイルを使って自動的にすべての処理
これは実運用時の処理ですよね？
　バックアップに限定すると単純に、コミットは最後に１回だけでも問題はないのですが、実運用時のバッチ処理時の場合は、処理時間だけに着目してコミットを最後だけに行うと、思わぬ障害に発生するので処理内容を検討して適切な間隔でコミットすることをお勧めします。

　バッチなどでは５０～１００個のＳＱＬを実行する毎にコミットを行っていますが・・・５０～１００個の根拠は 問題も発生しないし、処理時間的にも妥当と思われる　と思える程度です ^ ^;　また、利用するＴＢＬの利用状況によってはオート・コミットでないと危険と考えられる状況もありうるので、バックアップのリカバーとは別と考えて下さい。

補足

回答ありがとうございます。
バックアップは処理時間があまりかからないので、オートコミットのまま？で処理をしようと思います。
リカバリについては、オートコミットのままで処理をしてしまうと恐らく１０時間近くかかってしまうので、オートコミットを解除して処理をしようと思います。
そこで疑問なのが、バッチ処理でのバッチファイルの記述の方法です。
MySQL文であるSET autocommit=0;という記述はバッチファイル内に記述したのでOKなのかどうかとか、オートコミットを解除したあとにリカバー処理（mysql DB名 < "保存先.sql" -u root）を実行すると先に解除したオートコミットがまた有効になってしまうのではないか？
（バッチ処理でMySQL接続→オートコミットOFF→MySQL接続解除→復元）
また、qaz_qwerty_meさんが言われている５０～１００個のSQL毎にコミットをする方法はどのようにするのでしょうか？
バックアップしたSQLファイルに直接記述するしか方法がないのでしょうか？
何度も申し訳ないです。宜しくお願いします。

回答No.3

qaz_qwerty_me

明示的にコミット( commit )しなくても、自動的にコミットするオート・コミットという機能が動作していませんか？

参考に・・・
　http://dev.mysql.com/doc/refman/4.1/ja/commit.html

お礼

ありがとうございます。
ご指摘のとおりコミットをset autocommit=0としてから実行すると劇的に早くなりました。
ただ、windowsOSのためバッチファイルを使って自動的にすべての処理を行いたいのですが可能なのでしょうか？
バックアップのＳＱＬファイル内にset～と最後にcommitを入力すればできたのですが、バッチファイル内での処理で同様の処理は可能でしょうか？

回答No.2

yambejp

とりあえずバックアップだけが目的なら、var以下db名毎にアーカイブ
してしまうだけでもそれなりに効果があるでしょう。

補足

ＯＳがWindowsのためＶａｒというフォルダがありませんが、dataフォルダ配下のＤＢ名のフォルダをアーカイブするほうが早いのかもしれませんが復元方法については、アーカイブしたものを戻すだけで問題ないでしょうか？

回答No.1

qaz_qwerty_me

推測で申し訳ないですが・・・

SQL１個を処理して必ずコミットしていませんか？
リカバーですから、コミットは最後に１回すればいいので、これが原因だと実行速度は１桁は上がると思いますよ

補足

回答ありがとうございます。
コミットするというのはどういうことでしょうか？
バックアップファイルの内容を見る限りでは、テーブル作成のSQL文がありそのあとにデータのINSERT文が続けてありコミット（commit？)というのは見当たりませんでした。