開発のあいまに

更新系SQLを実行したあとcommit文を実行し忘れると事故が起きる

SQLDeveloperやsqlplusで、更新系SQL(insert/update/delete)を実行したあと、commit文を実行しないと、対象レコードをロックしたままになり、他のアプリの処理が全く終わらない事象が起きる。他のデータベース管理アプリはオートコミットしてくれるのが多いので忘れがちになりますが、これを本番環境でやってしまうと、サクラエディタでOracleのログファイルを排他で開き、Oracleが停止するくらい致命的。

ロック状況は下記SQLで確認できる。
select * from v$lock;
select * from v$session;

OracleのSQLをGUIで書く

AccessやSQLServerで便利な、GUI上でSQLをデザインする機能が、OracleのSQLDeveloperにもある。
データベースに接続しワークシートの「クエリー・ビルダー」を開くと、ビジュアルにSQLを作成できる。
左にあるツリービューからドラッグ＆ドロップでテーブルを追加し、列もドラッグ＆ドロップでJoinしていけるので、SQLのたたき台を作るのが楽に。

「クエリー・ビルダー」でデザインしたSQLは、「ワークシート」タブを開くことで確認できる。

 

Oracleでも断片化が進むと、思っている以上にスループットに影響する

SQL Serverだとテーブルやインデックスの断片化が進むと、オプティマイザに影響し、インデックスが使われなくなったり、SQLがパラレル処理されなくなるなどで、SQLの実行時間が極端に長くなる事象を、以前、実験結果から得ていましたが、Oracleでも同じ事象が発生し得るのか、My Oracle Supportで確認してみました。

結論的には、OracleでもSQL Serverと同じ事象が発生します。

要約すると下記が問題になります。

・Truncateした後に統計情報を更新しないと、DMLを処理するとき、残った不適切な統計情報により、効率的によくない実行計画を生成し性能が落ちる場合がある。
・インデックスを作成していないテーブルでも、結合処理を行う場合は統計情報の影響を受ける。
  例えば統計情報により、Nest Loopを選択するのか、Hash Joinを選択するのかを判断しますので、統計情報が不正の場合は効率がよくない結合処理を選択する可能性がある。
・統計情報が乖離する問題は、Truncateだけではなく、INSERT/UPDATE/DELETEいずれでも、大量に処理した場合は起こり得る。
・デフォルトでは毎晩、自動で統計情報を収集するジョブが実行されるので、統計情報の乖離が原因でSQLの実行計画が良くない選択をするのはまれ。

・テーブルの断片化が進むと索引のクラスタ化係数は大きくなります。実行計画を生成するとき、索引を使うかどうかはクラスタ化係数も考慮しているので、断片化が進むと実行計画に影響する。
・Oracleは自動的に断片化を解消する仕組みはない。
・DML(INSERT/UPDATE/DELETE)を繰り返すと、セグメントレベルの断片化が進行する。
・TRUNCATE TABLEを実行すると、セグメントレベルの断片化は解消するが、表レベルの断片化が起きる。
・セグメントレベルの断片化が進行すると、SQL実行時の実行計画が、インデックスを使用しない、SQLをパラレル実行しない、と選択し始める。
・Delete,Insertによるセグメントの断片化より、TRUNCATEによる表領域の断片化の方がスループットを低下させない。
・特定のテーブルでセグメントの断片化が進行しても、同じ表領域にある他のテーブルには影響しない。
・断片化が進行した場合、インデックスを使わないDMLでもスループットは低下する。

関連するOracleナレッジベースのドキュメントID
1720974.1
1751631.1

2015年のOTN掲示板事情

何年かぶりに、Oracleにどっぷりと浸かっています。OTNの掲示板で質問したくて掲示板を探していたら、閉鎖されてしまったことを知りました。

2010年に閉鎖された掲示板。閲覧はできる。
http://otn.oracle.co.jp/forum/index.jspa?categoryID=2

変わりに開設した掲示板もその後、閉鎖されてしまったらしい。閲覧もできない。
http://forums.oracle.com/forums/main.jspa?categoryID=484

最近は「初心者の部屋」「OTNカフェ」「ORACLE MASTERの部屋」という3つのコミュニティサイトを、自分自身のレベル、質問の難易度に合わせて利用するらしい。
https://community.oracle.com/community/other-languages/japanese/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3/places

LinuxにOracleをインストールした環境で、複数のインスタンスを再起動するコマンド

ORACLE_SID環境変数の値を変える事で、特定のインスタンスを再起動できます。

 

「orclA」というインスタンスを再起動する場合。

$ export ORACLE_SID=orclA
$ sqlplus /nolog
SQL> connect sys/(パスワード) as sysdba
SQL> shutdown immediate
SQL> startup

 

「orclB」というインスタンスを再起動する場合。

$ export ORACLE_SID=orclB
$ sqlplus /nolog
SQL> connect sys/(パスワード) as sysdba
SQL> shutdown immediate
SQL> startup

世界で最も使われているDBはMySQL

世界で最も使われているDBはMySQL。Oracleの3倍。
http://d.hatena.ne.jp/cypher256/20130209/p1

このページはJava屋さんが作ったので、SQLServerは除外されているけど、SQLServerのシェアはOracleより少し低い程度。
http://www.itmedia.co.jp/enterprise/articles/1005/12/news011.html

社内システムのDBシェアはOracleが半分を占めトップ。WEBサービスなどの社外向けシステムはMySQLが大半を占め、世界で最も使われているDBがMySQLなっているのが分かる。

業務システムで使うDBの選択基準の定石

365日24時間止められないシステムならORACLEを選択する。

平日9:00～21:00頃まで使われ、それ以外の時間帯をシステムメンテナンスに使えるなら、ライセンス料がOracleの半分で済み、開発難易度も低いSQLServerを選択する。

CPU使用率が100%になるようなシステム異常が発生した場合、SQLServerだと、SQLクエリアナライザなど、DB分析ツールの負荷が高い為、DBへ接続している全ての処理を一旦停止し、DB負荷を下げてからじゃないと、DBサーバーの改善に着手できない。

しかし、ORACLEではCPU使用率が100%になっていても、ADDMなどのDB分析ツールはサクサク動くので、リアルタイムにシステム異常を解消していける。この耐障害性では、まだまだ、Oracleに一日の長がある。

ただ、SQLServerでも、夜間や休日にメンテナンス処理をきちんと実施していれば、業務時間中にCPU使用率が100%になるようなシステム異常が発生する事はまず無い。

SQLServer、Oracle、どちらのEnterprise版にもテーブルのpage圧縮機能があり、100TBクラスのDBなら、データベースサイズが、どのDBにするかの判断基準にはならない。

年5万円で My Oracle Support を利用できる

My Oracle Supportを使えないとOracle開発構築は厳しいですが、年5万円程度のOPN契約（Silverレベル・パートナー）を結べば、Standard Edition クラスの製品で、My Oracle Supportを利用できるようになります。

Enterprise Edition クラスの製品で、My Oracle Supportを利用するには、 Goldレベル・パートナー（年30万円程度）以上の契約が必要です。

 「My Oracle Support」を使えれば、最新版インストーラ、日本語版インストー ルマニュアルをダウンロード でき、Oracle環境で問題が発生したらOracle社に直接問合わせできるので、 開発や障害対応が格段に楽になる。

OPN契約（Silverレベル・パートナー） http://www.oracle.com/partners/ja/opn-program/opn-details-by-levels/silver/index.html

OPN契約の種類、特典など http://www.oracle.com/partners/ja/opn-program/opn-s-new-p-recruit-221703-ja.pdf

 

x64アプリケーションでMStestを使う場合の注意点

MStestの初期設定ではx86が既定プロセッサになっていて、VSプロジェクトを「Any CPU」に設定しても、MStestのプロセッサタイプは変更されずx86のままなので、プロセッサタイプ（x64 or x86 ）に依存するdllを参照しているアプリケーションを実行すると、エラーが発生します。

例えば、x64版のOracle.DataAccess.dll を参照しているアプリケーションから、Open()メソッドでDBへ接続しようとすると、「'OraOLEDB.Oracle' プロバイダーはローカルのコンピューターに登録されていません。」Exceptionが発生します。

「Visual Studio メインメニュー　⇒　テスト　⇒　テスト設定　⇒　既定のプロセッサ アーキテクチャ」を「x64」へ変更すると解消されます。

Oracle 10G DBダンプ Exportコマンド バッチメモ

c:
cd C:\oracle\product\10.2.0\db_1\BIN
set NLS_LANG=Japanese_Japan.JA16SJIS
set Path=C:\oracle\product\10.2.0\client_1\bin;C:\oracle\product\10.2.0\db_1\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem
set time2=%time: =0%
exp userid/password@SID GRANTS=Y OWNER=(schemaA,schemaB,schemaC) ROWS=Y COMPRESS=Y DIRECT=Y recordlength=65535 FILE=E:\slp_%time2:~0,2%.dmp

exit

　

DB_Full_Backupバッチをダウンロード