一応メモっとこ。
ビンボなんで管理サーバの無いスタンドアロンなOracleを立てて、バックアップをリモートのWindows機で取る、なんて運用を結構します。
DOSバッチファイルはこんな感じです。
RMAN target sys/pass@dbname @C:\pathtobatch\rman.txt log C:\pathtobatch\rman.log
rman.txt の中身はこんな感じ。
run {
allocate channel Channel1 type disk format 'C:\path\to\backupset\bk_%u_%p_%c';
backup ( archivelog all delete input );
backup ( database include current controlfile );
}
allocate channel for maintenance device type disk;
delete obsolete device type disk;
DBAもいない現場では最低この程度を日次でやっといてもらう事でサイアクの事態だけ防ぐです。
小規模システム超モノグサ運用むけ。
ちなみにこの方法だと最新のバックアップListを含んだ制御ファイルが取れてないので、良い子は別途制御ファイルのバックアップを取りましょう。
無くてもなんとか不完全リカバリできるけど、Point In Timeなリカバリが出来なくなっちゃうので。
開発機でOracle の RMAN (Recovery Manager) でアーカイブログのバックアップを実行しようとするとエラーになった。
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: ファイルXXXXXの識別中にエラーが発生しました。
ORA-27041: ファイルをオープンできません。
OSから手動でアーカイブログを削除した事が原因らしい。
(制御ファイル中のlistと実ファイルが矛盾する)
バックアップの前に、
crosscheck archivelog all;
を実行すればOK。
参考サイト
[Oracle] RMANでのバックアップ実行時にアーカイブログファイルの識別エラーが発生する｜Archive Redo Blog
マイクロソフトのAccess 2010では、ODBCを通じてクラウド上のリレーショナルデータベースであるSQL Azureに直接接続可能だと、MS Officeチームのブログのエントリ「Access 2010 and SQL Azure」で紹介されています。
Access 2010 and SQL Azure – Microsoft Access – Site Home – MSDN Blogs
この機能を使えば、社内でSQL Serverの運用をすることなく、Access 2010から大規模なリレーショナルデータベースの機能を利用することができるようになります。」
Access 2010からODBCでクラウドのSQL Azureに接続可能。そのメリットは？
JetエンジンのままAccessを多人数で使うのは、排他制御の面でも、性能の面でも、あまり宜しくないんですけど、現場によっては結構重宝されていますよね。
自動でシュリンクしないからファイルがどんどん肥大化するし、しょっちゅう壊れるし。
せめてMSDE、今で言うとSQL Server Express Editionですかね、を使って欲しい訳です。
データベース管理者にとっては、SQL Serverのデータメンテナンスなど管理業務をAccessから行うことでずっと便利になるという指摘もいただきました。たしかに、それもぐっと楽になりそうです。
ODBCドライバさえあれば、OracleでもDB2でもデータ管理は出来ますね。
SQL大好きな私にとってAccessのクエリを使うのは苦痛なんですけど、エンドユーザにはGUIで操作できるAccessは結構使いやすいみたいですね。
RDMBSはコモディティ化した感があります。
今後のデータストアのプラットフォームは、完全にクラウド上での覇権争いになってきました。
KVSで無くRDBMSじゃ無いと駄目な案件を、SQL Azure と VM Forceが受け皿になっていきそうな予感。
どうするOracle陣営。
たまにやるので、メモ。
ORA-01745: ホスト/バインド変数名が無効です。
なんて言われて、INSERTが失敗する。
何のことはない、VALUES句の後で、カンマを入れ忘れてた。
こんな感じ。
VALUES (?,?,? ?)
正しくは、こう。
VALUES (?,?,?,?)
実際は、バインド変数の数はもっと沢山あって、改行とか入っているから
間違えに気づくのがちょっと遅かった。
Spring Framework の JdbcTemplate を使ってて、こんなんでました。
java.sql.SQLException: 列索引が無効です。
[commons-dbutils] エラー：列索引が無効です。 – メモ！メモ！ – Yahoo!ブログ
によると、
PreparedStatementのプレースホルダの数と、設定しているパラメータの数が合っていない。
らしい。
が、数は有っている。
散々悩んだ挙句、ResultSetのgetXX の引数が、途中で間違ってた。
こんな感じ。
bean.setValue1(rs.getString(1));
bean.setValue2(rs.getString(2));
bean.setValue8(rs.getString(8));
bean.setValue4(rs.getString(4));
bean.setValue5(rs.getString(5));
bean.setValue6(rs.getString(6));
実際は、列の数が200以上ある様なケースだったので、なかなか判らなかったのだ。
自戒の意味を込めて、書いておこう。