DROP SHADOW CTRL


GaragebandとiMovieで



検索

  • Google
フォト

Twitter

2024年9月
日 月 火 水 木 金 土
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

気まぐれ写真館

  • spider lily - 白と赤の彼岸花（曼珠沙華）

カテゴリー

Oracle

Apple

その他

  • ブログ de ノベルティ
    ノベルティグッズをただ、ただ、記録していくブログ。Mac De Oracleでは出来ないネタなので、別ブログを立てた次第。

Googleの広告



RSS

ブログ:ココログ

当サイトについて

プライバシーポリシー
■プライバシーポリシー

■個人情報の利用目的

　当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

■個人情報の第三者への開示

　当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

  • 本人のご了解がある場合
  • 法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。

■アクセス解析ツールについて

　当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

  • 目的：アクセス数を把握するため
  • 送信先：Google LCC
  • Googleは受け取った情報をどのように利用するか：Googleの規約に従います
  • 送信される情報：以下４点(R), ユーザー数、セッションの統計情報、おおよその位置情報、ブラウザとデバイスの情報

■広告の配信について

当サイトはGoogleとAmazonの広告を配信しています。

Googleについて

Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。

Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。

お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。

その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。

Amazonについて

AmazonはアソシエイトリンクのURLに含まれるパラメータを通じて利用者が直前に閲覧したアソシエイトサイトに関する情報などを収集し、これをアソシエイトパートナーに対する紹介料の算定、報告及び支払いに使用したり、アソシエイトパートナーによる複数のウェブサイトや商品戦略毎のパフォーマンスの分析に供したりしています。

  • アソシエイトパートナーの利用目的：閲覧の傾向や履歴の分析のため広告効果の分析のため
  • 外部送信プログラム名：Amazonアソシエイトプログラム
  • 送信先の会社名：アマゾンジャパン合同会社
  • 送信する情報の内容：閲覧した内容についての情報送信先の利用目的：自社の広告宣伝を目的とした広告情報の掲載のため、ウェブサイトやアプリの監視のため

Amazonによる個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。

■免責事項

　当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

■プライバシーポリシーの変更について

　当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。

« rownum使って満足しちゃってると..... #3 | トップページ | rownum使って満足しちゃってると.....おまけ »

2013年6月11日 (火) / Author : Hiroshi Sekiguchi.

rownum使って満足しちゃってると..... #4

つづきです。

前回の記事でも、まだ、ぼや〜〜〜〜んとしている方向け! :) #そうじゃない方も


以下は、リアルタムSQLモニタリングの結果ですが、rownumが効いたケース（上の結果）と効かなかったケース（下の結果）の違いは一目瞭然！
rownumの操作を示すCOUNT STOPKEYが上限の1000に満たない状態でId=4〜8のTC表とTB表の結合で100万回ループするNESTED LOOP結合が行われた後、Id=3,9でTA表と100万回ループするNESTED LOOP結合が行われているがよくわかります。


※前々回rownumが狙い通りに効いたケースのSQLリアルタイムモニタリング結果

=======================================================================================================================================================
| Id |             Operation             | Name  |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                                   |       | (Estim) |      | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=======================================================================================================================================================
|  0 | SELECT STATEMENT                  |       |         |      |        18 |     +0 |     1 |     1000 |      |       |          |                 |
|  1 |   COUNT STOPKEY                   |       |         |      |        18 |     +0 |     1 |     1000 |      |       |          |                 |
|  2 |    NESTED LOOPS                   |       |         |      |        18 |     +0 |     1 |     1000 |      |       |          |                 |
|  3 |     NESTED LOOPS                  |       |    1001 | 3798 |        18 |     +0 |     1 |     1000 |      |       |          |                 |
|  4 |      NESTED LOOPS                 |       |    2002 | 2796 |        18 |     +0 |     1 |     1000 |      |       |          |                 |
|  5 |       TABLE ACCESS BY INDEX ROWID | TC    |    4004 |  571 |        18 |     +0 |     1 |     1000 |   53 |   1MB |          |                 |
|  6 |        INDEX RANGE SCAN           | PK_TC |         |   13 |        18 |     +0 |     1 |     1000 |    3 | 49152 |          |                 |
|  7 |       TABLE ACCESS BY INDEX ROWID | TB    |       1 |    1 |        18 |     +0 |  1000 |     1000 |    2 | 65536 |          |                 |
|  8 |        INDEX UNIQUE SCAN          | PK_TB |       1 |      |        18 |     +0 |  1000 |     1000 |    2 | 40960 |          |                 |
|  9 |      INDEX UNIQUE SCAN            | PK_TA |       1 |      |        18 |     +0 |  1000 |     1000 |    1 |  8192 |          |                 |
| 10 |     TABLE ACCESS BY INDEX ROWID   | TA    |       1 |    1 |        18 |     +0 |  1000 |     1000 |    1 |  8192 |          |                 |
=======================================================================================================================================================

※前回rownumが狙い通りに効かなかったケースのSQLリアルタイムモニタリング結果

=========================================================================================================================================
| Id |             Operation             | Name  |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Activity | Activity Detail |
|    |                                   |       | (Estim) |       | Active(s) | Active |       | (Actual) |   (%)    |   (# samples)   |
=========================================================================================================================================
|  0 | SELECT STATEMENT                  |       |         |       |           |        |     1 |          |          |                 |
|  1 |   COUNT STOPKEY                   |       |         |       |           |        |     1 |          |          |                 |
|  2 |    NESTED LOOPS                   |       |         |       |           |        |     1 |          |          |                 |
|  3 |     NESTED LOOPS                  |       |    1000 | 37910 |         2 |     +2 |     1 |        0 |          |                 |
|  4 |      NESTED LOOPS                 |       |   20001 | 27906 |         2 |     +2 |     1 |       1M |          |                 |
|  5 |       TABLE ACCESS BY INDEX ROWID | TC    |   40003 |  5675 |         3 |     +1 |     1 |       1M |    25.00 | Cpu (1)         |
|  6 |        INDEX RANGE SCAN           | PK_TC |         |   109 |         2 |     +2 |     1 |       1M |    25.00 | Cpu (1)         |
|  7 |       TABLE ACCESS BY INDEX ROWID | TB    |       1 |     1 |         3 |     +2 |    1M |       1M |    25.00 | Cpu (1)         |
|  8 |        INDEX UNIQUE SCAN          | PK_TB |       1 |       |         2 |     +2 |    1M |       1M |    25.00 | Cpu (1)         |
|  9 |      INDEX UNIQUE SCAN            | PK_TA |       1 |       |           |        |    1M |          |          |                 |
| 10 |     TABLE ACCESS BY INDEX ROWID   | TA    |       1 |     1 |           |        |       |          |          |                 |
=========================================================================================================================================

rownumって、取得する行数の制限なのであって、NESTED LOOP結合のループ回数を制限するものではないんですよね。

rownumを使っているからもう安心！　（キリっ！　

と、言えない状況もあるということはお忘れなく！

現状、この弱点を回避する方法は無いのですから....

・rownum使って満足しちゃってると..... #1
・rownum使って満足しちゃってると..... #2
・rownum使って満足しちゃってると..... #3

投稿日時 2013年6月11日 (火) 01時00分 Oracle, チューニング, SQL | |

トラックバック


この記事へのトラックバック一覧です： rownum使って満足しちゃってると..... #4:

コメント

はじめまして、ブログ楽しく読ませて頂きました。
坪江といいます。
Oracleはなんか難しい感じがして馴染めませんが、ブログ見ながら頑張ります＾＾

投稿: 坪江 | 2013年6月19日 (水) 19時41分

コメントを書く