What is the DUAL table costing you?
みなさんには全然関係ないことなのですが、
私のブログがGoogle Japanから一時期完全に抹消されてました(T-T)。
原因不明！
blog形式にそろそろ限界を感じていたので、FC2にお引越ししてみました。
みすぼらしいページですが、色々自由にできるので少しずつ発展していければ
と思います。
今回はSearchOracle.comからdualテーブルに関するトピックの引用です。
dualテーブルはたぶん説明不要とは思いますが、Oracleデータベースを作成すると、
必ず作成されるDummyテーブルです。OracleのSQL関数などを使用したいけど、
別にデータにアクセスする必要は無い場合に使用します。
dualの説明は他のサイトにもたくさんあるので早速ですが
引用に入りたいと思います。
■ SearchOracle.com
http://searchoracle.techtarget.com/
■ Excerpt(引用)
What is the DUAL table costing you?
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Introduction
The DUAL table is one of the first things we learn as Oracle professionals.
It is created by default as a single row table, understood by the optimizer
and available to everyone for selection. We typically use this table to
select the name of the current user, ping the database or to generate the
next sequence number for a surrogate key. Chances are, few of us consider
the impact of querying this table on our applications. This article will
explore the cost of querying the DUAL table and offer some less expensive
options to optimize application processing.
◆ Cost prior to Oracle 10g
Prior to 10g the cost of querying the DUAL table is relatively expensive.
The following diagram shows the access path from the optimizer's execution
plan as a full scan of the DUAL table. The SQL statement execution statistics
show querying the DUAL table will cost a minimum of three consistent gets.
set autotrace traceonly
SELECT user FROM dual;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'DUAL'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
209 bytes sent via SQL*Net to client
233 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
You can create your own less expensive DUAL as an indexed-organized table
(IOT). In the following diagram, the access path from the optimizer's
execution plan shows an index (FULL SCAN) of the BETTER_DUAL table.
The SQL statement execution statistics show the number of consistent gets
have dropped from three to one.
create table better_dual
(dummy varchar2(1) null
,constraint better_dual_pk primary key (dummy)
)
organization index;
insert into better_dual values ('X');
commit;
execute dbms_stats.gather_table_stats ('SA','BETTER_DUAL');
-- or
analyze table better_dual compute statistics;
set autotrace traceonly
SELECT user FROM better_dual;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1)
1 0 INDEX (FULL SCAN) OF 'BETTER_DUAL_PK' (UNIQUE) (Cost=1 Card=1)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1 consistent gets
0 physical reads
0 redo size
206 bytes sent via SQL*Net to client
234 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
◆ Cost in Oracle 10g
In Oracle 10g the overhead of performing logical I/O for our query has been
eliminated. The access path from the optimizer's execution plan shows a new
fast dual operation. SQL statement execution statistics show consistent
gets are zero.
Note: A 'select * from dual' SQL statement still behaves as it did prior to
10g and requires three consistent gets to satisfy the query. Changing your
code to 'select 1 from dual' will eliminate consistent gets.
set autotrace traceonly
SELECT user FROM dual;
Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953
-----------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
331 bytes sent via SQL*Net to client
377 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
◆ Conclusion
We've seen that taking the Oracle DUAL table for granted may be costing you
more than you thought. Whether you're on Oracle 9i or 10g you should rethink
your use of the DUAL table and optimize processing by considering some of
the alternatives we introduced in this article!
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
なっているところがあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Introduction
はじめに
The DUAL table is one of the first things we learn as Oracle professionals.
DUALテーブルは私達がOracleのプロとして最初に覚えるものの１つです。
It is created by default as a single row table, understood by the optimizer
and available to everyone for selection.
それは１行のデータを持ち、オプティマイザに認識され、
誰でもSELECT可能なテーブルとしてデフォルトで作成されます。
We typically use this table to select the name of the current user, ping
the database or to generate the next sequence number for a surrogate key.
通常このテーブルはカレントユーザ名のSELECT、データベースのping、
次シーケンス番号の生成などで使用します。
Chances are, few of us consider the impact of querying this table on our
applications.
恐らくこのテーブルのクエリによるアプリケーションへの影響を考える人は
ほとんどいないでしょう。
This article will explore the cost of querying the DUAL table and offer
some less expensive options to optimize application processing.
この記事はDUALテーブル検索のコストを調査し、アプリケーション処理最適化の為の
より低コストな選択肢をいくつか提案します。
◆ Cost prior to Oracle 10g
Oracle 10g以前のコスト
Prior to 10g the cost of querying the DUAL table is relatively expensive.
10g以前のDUALテーブル検索のコストは比較的高いです。
The following diagram shows the access path from the optimizer's execution
plan as a full scan of the DUAL table.
以下の図はオプティマイザによるDUALテーブルフルスキャンの実行計画の
アクセスパスを示しています。
The SQL statement execution statistics show querying the DUAL table will
cost a minimum of three consistent gets.
SQL実行統計はDUALテーブル検索は最低３ブロックのバッファ読み込みが
必要になることを示しています。
You can create your own less expensive DUAL as an indexed-organized table
(IOT).
あなた用の低コストなDUALを索引構成表(IOT)として作成することができます。
In the following diagram, the access path from the optimizer's
execution plan shows an index (FULL SCAN) of the BETTER_DUAL table.
以下の図では、オプティマイザ実行計画のアクセスパスがBETTER_DUALテーブルの
インデックス（フルスキャン）であることを示しています。
The SQL statement execution statistics show the number of consistent gets
have dropped from three to one.
SQL実行統計はバッファアクセスのブロック数が３から１に減っていることを
示しています。
◆ Cost in Oracle 10g
Oracle 10gのコスト
In Oracle 10g the overhead of performing logical I/O for our query has been
eliminated.
Oracle 10gでは、検索の為の論理I/O処理のオーバヘッドが無くなっています。
The access path from the optimizer's execution plan shows a new
fast dual operation.
オプティマイザ実行計画のアクセスパスは新しいfast dual operationを
示しています。
SQL statement execution statistics show consistent gets are zero.
SQL実行統計はバッファブロックアクセスがゼロであることを示しています。
Note: A 'select * from dual' SQL statement still behaves as it did prior to
10g and requires three consistent gets to satisfy the query.
注意: 'select * from dual'のSQL文はまだ10g以前の動作と同じように動きます。
そして、検索を満たす為に３回のバッファブロックアクセスを要求します。
Changing your code to 'select 1 from dual' will eliminate consistent gets.
あなたのコードを'select 1 from dual'変更すれば、バッファブロックアクセスは
無くなります。
◆ Conclusion
結論
We've seen that taking the Oracle DUAL table for granted may be costing you
more than you thought.
私達はここまでで、OracleのDUALテーブルを当たり前のように使用することは、
あなたが思っていた以上にコストがかけるかもしれないということを見てきました。
Whether you're on Oracle 9i or 10g you should rethink your use of the DUAL
table and optimize processing by considering some of the alternatives
we introduced in this article!
あなたがOracle 9iか10gどちらを使っているにせよ、DUALテーブルの使用と
処理最適化について、この記事で紹介した代替案の適用を再考してみては
いかがでしょうか。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
単語/英文解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
The DUAL table is one of the first things we learn as Oracle professionals.
※weの前のthatが省略されている。
typically:典型的に,一般的に,通常
ping:相手(ここではDB)の起動確認用のメッセージ送受信
Chances are:文の初めに使用される場合は、可能性を示唆する
Prior to:以前
relatively:比較的
diagram:図
access path:sqlが実際のデータにたどり着くまでのアクセス方式の経緯
optimizer's execution plan:実行計画
indexed-organized table(IOT):索引構成表
eliminated:削除された
than someone thought:someoneが思ったより
alternatives:代替物
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★
※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
☆服が似合っている人に言うのは？
◆it's so like you.
◆that's very you.
◆that's typical of you.
┗○結果を見る
締切：2007年03月08日18時00分
協力：クリックアンケート
こたえは次回に発表します。
■ 前回のこたえ
☆「チャック開いてますよ」って言いたい時に一番使わないフレーズは？
◆Your barn door is open
◆XYZ
◆Your fastener is open
◆You are flying low
◆Your zipper is open
○結果を見る
┗http://clickenquete.com/a/r.php?Q0019492C633e
Your fastener is openだと機械が喋っているような
無機質な感じになります。たぶんこれが一番使われていないと
思われます。
Your barn door is openはちょっと古い表現で、
「社会の窓が～」的な感じでしょうか。
XYZはeXamine Your Zipperの略です。
you are flying lowは低空飛行のflying lowと
チャックのflyをかけた冗談です。
Your zipper is openはノーマルな表現です。
他にもPDQ(pretty done quick)などがあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
大規模なバッチ処理やアクセスが殺到するようなアプリケーションでは、
このコンマ数秒の改善が数時間の違いをもたらす場合があります。
以下念のためdualの使用例です。
例）select sysdate from dual;
これでデータベースの日付を取得できます。
sqlplus大好きな先輩が電卓代わりに使用しているのを見たこともあります（笑）
例）select 10+165 from dual;
以前、中国にアプリケーション開発を委託したとき、
Cプログラムのテキスト操作などでいちいちSQLでテキスト操作していて
びっくりしたことがあります。
このテーブルを削除したり、データをINSERT/DELETEしたりすると
想像以上に痛い目に会います（って普通誰もしないですよね(^-^;
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。
和歌山のAdventure World in Shirama(AWS)に赤ちゃん双子パンダを
見に行ってきました。生きた"たれぱんだ"が見れました。
この園内で８匹目のパンダで、中国を除けば世界一のパンダ飼育サイトだそうです。
象の鼻にバナナを直接プレゼントしたり、イルカを調教したり、
カバの口に餌投げ込んだり、予想以上に楽しいところでした。
それではまた。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。
簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274
バックナンバーはこちら
http://imoment.web.fc2.com/
登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm
私のブログがGoogle Japanから一時期完全に抹消されてました(T-T)。
原因不明！
blog形式にそろそろ限界を感じていたので、FC2にお引越ししてみました。
みすぼらしいページですが、色々自由にできるので少しずつ発展していければ
と思います。
今回はSearchOracle.comからdualテーブルに関するトピックの引用です。
dualテーブルはたぶん説明不要とは思いますが、Oracleデータベースを作成すると、
必ず作成されるDummyテーブルです。OracleのSQL関数などを使用したいけど、
別にデータにアクセスする必要は無い場合に使用します。
dualの説明は他のサイトにもたくさんあるので早速ですが
引用に入りたいと思います。
■ SearchOracle.com
http://searchoracle.techtarget.com/
■ Excerpt(引用)
What is the DUAL table costing you?
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Introduction
The DUAL table is one of the first things we learn as Oracle professionals.
It is created by default as a single row table, understood by the optimizer
and available to everyone for selection. We typically use this table to
select the name of the current user, ping the database or to generate the
next sequence number for a surrogate key. Chances are, few of us consider
the impact of querying this table on our applications. This article will
explore the cost of querying the DUAL table and offer some less expensive
options to optimize application processing.
◆ Cost prior to Oracle 10g
Prior to 10g the cost of querying the DUAL table is relatively expensive.
The following diagram shows the access path from the optimizer's execution
plan as a full scan of the DUAL table. The SQL statement execution statistics
show querying the DUAL table will cost a minimum of three consistent gets.
set autotrace traceonly
SELECT user FROM dual;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'DUAL'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
209 bytes sent via SQL*Net to client
233 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
You can create your own less expensive DUAL as an indexed-organized table
(IOT). In the following diagram, the access path from the optimizer's
execution plan shows an index (FULL SCAN) of the BETTER_DUAL table.
The SQL statement execution statistics show the number of consistent gets
have dropped from three to one.
create table better_dual
(dummy varchar2(1) null
,constraint better_dual_pk primary key (dummy)
)
organization index;
insert into better_dual values ('X');
commit;
execute dbms_stats.gather_table_stats ('SA','BETTER_DUAL');
-- or
analyze table better_dual compute statistics;
set autotrace traceonly
SELECT user FROM better_dual;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1)
1 0 INDEX (FULL SCAN) OF 'BETTER_DUAL_PK' (UNIQUE) (Cost=1 Card=1)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1 consistent gets
0 physical reads
0 redo size
206 bytes sent via SQL*Net to client
234 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
◆ Cost in Oracle 10g
In Oracle 10g the overhead of performing logical I/O for our query has been
eliminated. The access path from the optimizer's execution plan shows a new
fast dual operation. SQL statement execution statistics show consistent
gets are zero.
Note: A 'select * from dual' SQL statement still behaves as it did prior to
10g and requires three consistent gets to satisfy the query. Changing your
code to 'select 1 from dual' will eliminate consistent gets.
set autotrace traceonly
SELECT user FROM dual;
Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953
-----------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
331 bytes sent via SQL*Net to client
377 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
◆ Conclusion
We've seen that taking the Oracle DUAL table for granted may be costing you
more than you thought. Whether you're on Oracle 9i or 10g you should rethink
your use of the DUAL table and optimize processing by considering some of
the alternatives we introduced in this article!
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
なっているところがあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Introduction
はじめに
The DUAL table is one of the first things we learn as Oracle professionals.
DUALテーブルは私達がOracleのプロとして最初に覚えるものの１つです。
It is created by default as a single row table, understood by the optimizer
and available to everyone for selection.
それは１行のデータを持ち、オプティマイザに認識され、
誰でもSELECT可能なテーブルとしてデフォルトで作成されます。
We typically use this table to select the name of the current user, ping
the database or to generate the next sequence number for a surrogate key.
通常このテーブルはカレントユーザ名のSELECT、データベースのping、
次シーケンス番号の生成などで使用します。
Chances are, few of us consider the impact of querying this table on our
applications.
恐らくこのテーブルのクエリによるアプリケーションへの影響を考える人は
ほとんどいないでしょう。
This article will explore the cost of querying the DUAL table and offer
some less expensive options to optimize application processing.
この記事はDUALテーブル検索のコストを調査し、アプリケーション処理最適化の為の
より低コストな選択肢をいくつか提案します。
◆ Cost prior to Oracle 10g
Oracle 10g以前のコスト
Prior to 10g the cost of querying the DUAL table is relatively expensive.
10g以前のDUALテーブル検索のコストは比較的高いです。
The following diagram shows the access path from the optimizer's execution
plan as a full scan of the DUAL table.
以下の図はオプティマイザによるDUALテーブルフルスキャンの実行計画の
アクセスパスを示しています。
The SQL statement execution statistics show querying the DUAL table will
cost a minimum of three consistent gets.
SQL実行統計はDUALテーブル検索は最低３ブロックのバッファ読み込みが
必要になることを示しています。
You can create your own less expensive DUAL as an indexed-organized table
(IOT).
あなた用の低コストなDUALを索引構成表(IOT)として作成することができます。
In the following diagram, the access path from the optimizer's
execution plan shows an index (FULL SCAN) of the BETTER_DUAL table.
以下の図では、オプティマイザ実行計画のアクセスパスがBETTER_DUALテーブルの
インデックス（フルスキャン）であることを示しています。
The SQL statement execution statistics show the number of consistent gets
have dropped from three to one.
SQL実行統計はバッファアクセスのブロック数が３から１に減っていることを
示しています。
◆ Cost in Oracle 10g
Oracle 10gのコスト
In Oracle 10g the overhead of performing logical I/O for our query has been
eliminated.
Oracle 10gでは、検索の為の論理I/O処理のオーバヘッドが無くなっています。
The access path from the optimizer's execution plan shows a new
fast dual operation.
オプティマイザ実行計画のアクセスパスは新しいfast dual operationを
示しています。
SQL statement execution statistics show consistent gets are zero.
SQL実行統計はバッファブロックアクセスがゼロであることを示しています。
Note: A 'select * from dual' SQL statement still behaves as it did prior to
10g and requires three consistent gets to satisfy the query.
注意: 'select * from dual'のSQL文はまだ10g以前の動作と同じように動きます。
そして、検索を満たす為に３回のバッファブロックアクセスを要求します。
Changing your code to 'select 1 from dual' will eliminate consistent gets.
あなたのコードを'select 1 from dual'変更すれば、バッファブロックアクセスは
無くなります。
◆ Conclusion
結論
We've seen that taking the Oracle DUAL table for granted may be costing you
more than you thought.
私達はここまでで、OracleのDUALテーブルを当たり前のように使用することは、
あなたが思っていた以上にコストがかけるかもしれないということを見てきました。
Whether you're on Oracle 9i or 10g you should rethink your use of the DUAL
table and optimize processing by considering some of the alternatives
we introduced in this article!
あなたがOracle 9iか10gどちらを使っているにせよ、DUALテーブルの使用と
処理最適化について、この記事で紹介した代替案の適用を再考してみては
いかがでしょうか。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
単語/英文解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
The DUAL table is one of the first things we learn as Oracle professionals.
※weの前のthatが省略されている。
typically:典型的に,一般的に,通常
ping:相手(ここではDB)の起動確認用のメッセージ送受信
Chances are:文の初めに使用される場合は、可能性を示唆する
Prior to:以前
relatively:比較的
diagram:図
access path:sqlが実際のデータにたどり着くまでのアクセス方式の経緯
optimizer's execution plan:実行計画
indexed-organized table(IOT):索引構成表
eliminated:削除された
than someone thought:someoneが思ったより
alternatives:代替物
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★
※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
☆服が似合っている人に言うのは？
◆it's so like you.
◆that's very you.
◆that's typical of you.
┗○結果を見る
締切：2007年03月08日18時00分
協力：クリックアンケート
こたえは次回に発表します。
■ 前回のこたえ
☆「チャック開いてますよ」って言いたい時に一番使わないフレーズは？
◆Your barn door is open
◆XYZ
◆Your fastener is open
◆You are flying low
◆Your zipper is open
○結果を見る
┗http://clickenquete.com/a/r.php?Q0019492C633e
Your fastener is openだと機械が喋っているような
無機質な感じになります。たぶんこれが一番使われていないと
思われます。
Your barn door is openはちょっと古い表現で、
「社会の窓が～」的な感じでしょうか。
XYZはeXamine Your Zipperの略です。
you are flying lowは低空飛行のflying lowと
チャックのflyをかけた冗談です。
Your zipper is openはノーマルな表現です。
他にもPDQ(pretty done quick)などがあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
大規模なバッチ処理やアクセスが殺到するようなアプリケーションでは、
このコンマ数秒の改善が数時間の違いをもたらす場合があります。
以下念のためdualの使用例です。
例）select sysdate from dual;
これでデータベースの日付を取得できます。
sqlplus大好きな先輩が電卓代わりに使用しているのを見たこともあります（笑）
例）select 10+165 from dual;
以前、中国にアプリケーション開発を委託したとき、
Cプログラムのテキスト操作などでいちいちSQLでテキスト操作していて
びっくりしたことがあります。
このテーブルを削除したり、データをINSERT/DELETEしたりすると
想像以上に痛い目に会います（って普通誰もしないですよね(^-^;
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。
和歌山のAdventure World in Shirama(AWS)に赤ちゃん双子パンダを
見に行ってきました。生きた"たれぱんだ"が見れました。
この園内で８匹目のパンダで、中国を除けば世界一のパンダ飼育サイトだそうです。
象の鼻にバナナを直接プレゼントしたり、イルカを調教したり、
カバの口に餌投げ込んだり、予想以上に楽しいところでした。
それではまた。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。
簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274
バックナンバーはこちら
http://imoment.web.fc2.com/
登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm
ラベル: dual, dummy, oracle, panda, performance
コメントを投稿