Mac De Oracle: Opera

DROP SHADOW CTRL

TEXT DROP SHADOW OFF

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

2024年12月
日	月	火	水	木	金	土
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	31

最近のトラックバック

[memo]メモを取りつつ楽しめるようなスタイル (wmo6hash::blog)
ダーリンはGoogleで軽食なり。 (今日のゴハン)
�� プログラムは読む時間の方が長い - 遥か彼方の彼方から (�� プログラムは読む時間の方が長い - 遥か彼方の彼方から)
今流行のケブンリッジ関数・・・しってました！？ (あにずむ)
poken (drmarのメモ)
Photo exhibition "Natural Faces of AIDS Orphans"　写真展「エイズ孤児の素顔」@JICA地球ひろば　広尾 (メガ放談)
創る心とおもてなし―第1回 Webエンジニア料理対決に参加する (Kwappa開発室)
創る心とおもてなし～第一回webエンジニア料理対決に参加した (Mac De Oracle)
徹底比較!! PostgreSQL vs MySQLパート2 with 勝手に vs Firebird (14) (キムラデービーブログ)
Oracle de XMLDB #18 (discus)

Oracle

OTN US

Apple

その他

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

Googleの広告

RSS

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プライバシー規約をご覧ください。

■免責事項

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

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

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

2023年2月 2日 (木)

join elimination（結合の排除）のバリエーション / FAQ

Previously on Mac De Oracle
SQL*Plus -Fastオプション / FAQでした。

今日は、結合排除のバリエーションをいくつか紹介しておこうと思います。
なんどか説明していた無駄に結合してないですよね？の例は、参照整合性制約を頼りに結合排除が行われるものでした。

今日はそれに加えて、典型的な例を2つ紹介しておきたいと思います。（ここ”　”、試験に出ませんよ！w　でないけど大切：）

一つ目は、結合列がそれぞれユニークキーかプライマリキーで一意で、1 : 0..1 で外部結合されるケース
結合の排除は、その結合を排除しても結果に影響しなことが自明な場合に発動するので、条件を満たしています。ただ、参照整合性制約のパターン同様に、SQL文を見ただけでは気づけないですよね。
あれ、実行計画にSQL文に記載されている表がない！？　で制約を見てみて、あ”〜〜〜〜理解。みたいなw

実行計画ではSQLモニターも含め、Join Eliminationしたことを明示的に示すコメント等はありません。結合が消えていることで気づくことが多いわけですw（よーく考えたら、その結合イラねーじゃんというわけですけどもw0

  1* CREATE TABLE foo (id NUMBER PRIMARY KEY, note VARCHAR2(100))

表が作成されました。

  1* CREATE TABLE bar (id NUMBER PRIMARY KEY, memo VARCHAR2(100))

表が作成されました。

  1  SELECT
  2    foo.id
  3    , foo.note
  4  FROM
  5    foo
  6    LEFT OUTER JOIN bar
  7    ON
  8*     foo.id = bar.id

実行計画
----------------------------------------------------------
Plan hash value: 1245013993

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO  |     1 |    65 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

この手の制約による結合の排除は、前提になる制約が結合排除の条件からはずれると排除されなくなります。
たとえば、前述の例で、それぞれの表を主キーで　1:0..1 で外部結合していましたよね？
それが仕様変更で、片方の方の主キーが複合主キーになってしまい。1:* の外部結合になってしまうと。。。。結合排除できなくなります。排除した場合、クエリー結果に影響するから。

  1  CREATE TABLE foo2 (
  2    id NUMBER
  3   , note VARCHAR2(100)
  4   , PRIMARY KEY (id)
  5* )

表が作成されました。

  1  CREATE TABLE bar2 (
  2    id NUMBER
  3   , sq NUMBER NOT NULL
  4   , memo VARCHAR2(100)
  5   , PRIMARY KEY (id, sq)
  6* )

表が作成されました。

  1  SELECT
  2    foo2.id
  3    , foo2.note
  4  FROM
  5    foo2
  6    LEFT OUTER JOIN bar2
  7    ON
  8*     foo2.id = bar2.id

実行計画
----------------------------------------------------------
Plan hash value: 3679270243

----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |     1 |    78 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS OUTER|             |     1 |    78 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| FOO2        |     1 |    65 |     2   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | SYS_C009222 |     1 |    13 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("FOO2"."ID"="BAR2"."ID"(+))

では、結合の排除のもう一つの例。これは制約というより、排除を狙った意図的な方法です。
動的なSQlが利用されているアプリケーションで使われていることが多い印象ですが、この方法は好き嫌い激しいかもしれないですね。私は好きじゃないですw　が偶にみます。

このクエリは、1:* の外部結合なのですが、WHERE 1=0　によって結果を返しません。なのでクエリー結果に影響しないことが自明なので排除されている。ということになります。

   1  SELECT
   2    foo2.id
   3   , foo2.note
   4  FROM
   5    foo2
   6    LEFT OUTER JOIN
   7    (
   8       SELECT * FROM bar2 WHERE 1=0
   9    ) bar2
  10    ON
  11*     foo2.id = bar2.id

 実行計画
 ----------------------------------------------------------
 Plan hash value: 2844017661

 --------------------------------------------------------------------------
 | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
 --------------------------------------------------------------------------
 |   0 | SELECT STATEMENT  |      |     1 |    65 |     2   (0)| 00:00:01 |
 |   1 |  TABLE ACCESS FULL| FOO2 |     1 |    65 |     2   (0)| 00:00:01 |
 --------------------------------------------------------------------------

 Note
 -----
    - dynamic statistics used: dynamic sampling (level=2)

ということで、今年も残すところあと11ヶ月ですねw
長いことやってたプロジェクトが一つ形になったみたいな、ならないような、hear through the grapevine.

では、また。

・Join Elimination（結合の排除）と参照整合性制約　/ FAQ
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination

投稿日時 2023年2月 2日 (木) 00時00分チューニング, FAQ, SQL, Opera, パフォーマンス | 固定リンク | 0 | コメント (0)

2022年12月 2日 (金)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL

Previously on Mac De Oracle...
帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022始まっちゃいましたw

Day 1は, 19cまでのINTERSECTに加え, 21c（正確には20c）からサポートされたINTRESECT ALLの実行計画というレントゲンはどう見えるのか？を確認しました.
21cからはHASH操作が加わっているとことは興味深いので, HASH操作について観点を変えて実行計画というレントゲンを見ておかねば, という気がしていますね. 今のところ, おまけとして考えているところですw（ネタがキツくなったら普通にやるかもw）

ということで, Day 2の窓を開けましょう！

なお, 今回のSQL文の結果セットはソートされているように並んでいますが, たまたま昇順に並んでいるだけなので, ソートが必要な場合は, 必ず, ORDER BY句を付けてくださいね.

INTERSECTと同様に, 19cまでは, ALLがサポートされていなかったOracleの方言である集合演算 MINUS にも MINUS ALLがサポートされました.
21c以降で利用できます. 実際には20cですが世に出てくることは無かったわけで,　事実上21c以降といってもいいですよね（おそらく）

21cでみてみましょう.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Day 1と同じ表とデータを利用します(再掲). 意図的に, 該当表には索引を作成していません.

SCOTT@orclpdb1> @day2
  1  SELECT
  2    num
  3  FROM
  4*   groupa

       NUM
----------
         1
         2
         2
         3
         4
         4
         5

7行が選択されました.

  1  SELECT
  2    num
  3  FROM
  4*   groupb

       NUM
----------
         0
         2
         3
         3
         4
         4
         4
         7

8行が選択されました.

今回の主役, MINUS ALLの実行計画という名のレントゲンから診てみます.

OperationにMINUS ALLと現れています. わかりやすいですね. また, ここでもHASH操作が現れています. 21cの特徴でもあるので頭の片隅に置いといた方が良さそうです.

  1  SELECT
  2    num
  3  FROM
  4    groupa
  5  MINUS ALL
  6  SELECT
  7    num
  8  FROM
  9*   groupb

       NUM
----------
         1
         2
         5

実行計画
----------------------------------------------------------
Plan hash value: 895579533

-----------------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     7 |    45 |     8  (25)| 00:00:01 |
|   1 |  MINUS ALL HASH    |        |       |       |            |          |
|   2 |   TABLE ACCESS FULL| GROUPA |     7 |    21 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| GROUPB |     8 |    24 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         12  consistent gets
          0  physical reads
          0  redo size
        648  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

次にこれまでもサポートされていた, MINUSの実行計画という名のレントゲンから診てみます.

これも判断しやすいですね. キーワードとなるMINUSが, Operationに現れています. 同様に, HASHも.

  1  SELECT
  2    num
  3  FROM
  4    groupa
  5  MINUS
  6  SELECT
  7    num
  8  FROM
  9*   groupb

       NUM
----------
         1
         5


実行計画
----------------------------------------------------------
Plan hash value: 2352437695

-----------------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     7 |    45 |     8  (25)| 00:00:01 |
|   1 |  MINUS HASH        |        |       |       |            |          |
|   2 |   TABLE ACCESS FULL| GROUPA |     7 |    21 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| GROUPB |     8 |    24 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         12  consistent gets
          0  physical reads
          0  redo size
        640  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          2  rows processed

次に, 索引アクセスがある場合はどうなるかを確認します.　利用するデータや表はDay1と同じです.(再掲)
なお, 索引等の情報は前回のエントリーをご覧ください

  1  SELECT
  2    unique_id
  3  FROM
  4    tab311
  5  WHERE
  6*   unique_id BETWEEN 1 AND 50

 UNIQUE_ID
----------
         1
         1
         1
         2
         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
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        44
        45
        46
        47
        48
        49
        50

53行が選択されました.

  1  SELECT
  2    unique_id
  3  FROM
  4    tab312
  5  WHERE
  6*   unique_id BETWEEN 25 AND 75

 UNIQUE_ID
----------
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        44
        45
        46
        47
        48
        49
        50
        51
        52
        53
        54
        55
        56
        57
        58
        59
        60
        61
        62
        63
        64
        65
        66
        67
        68
        69
        70
        71
        72
        73
        74
        75

51行が選択されました.

まずは, MINUS ALLから

Table Full Scanであろうが, Index Range Scanであろうが, HASH操作になるというのも特徴のようですね. 興味深いです.

  1  SELECT
  2    unique_id
  3  FROM
  4    tab311
  5  WHERE
  6    unique_id BETWEEN 1 AND 50
  7  MINUS ALL
  8  SELECT
  9    unique_id
 10  FROM
 11    tab312
 12  WHERE
 13*   unique_id BETWEEN 25 AND 75

 UNIQUE_ID
----------
         1
         1
         1
         2
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24

27行が選択されました.


実行計画
----------------------------------------------------------
Plan hash value: 381125746

---------------------------------------------------------------------------------
| Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |             |    50 |   612 |     8  (25)| 00:00:01 |
|   1 |  MINUS ALL HASH   |             |       |       |            |          |
|*  2 |   INDEX RANGE SCAN| TAB311_PK   |    50 |   300 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN| IX01_TAB312 |    52 |   312 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50)
   3 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75)


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          6  consistent gets
          0  physical reads
          0  redo size
       1040  bytes sent via SQL*Net to client
         63  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         27  rows processed

MINUSはどうでしょう？

お! やはり, 挙動が変わりますね. これは, 索引を利用することを重要視した結果と言えそうです. SORT UNIQUE NOSORTなので, ソートなしでUNIQUE操作を行っています. ソートのバイバスを重要視したということになりますね.
ここも非常に興味深い動きですね.

  1  SELECT
  2    unique_id
  3  FROM
  4    tab311
  5  WHERE
  6    unique_id BETWEEN 1 AND 50
  7  MINUS
  8  SELECT
  9    unique_id
 10  FROM
 11    tab312
 12  WHERE
 13*   unique_id BETWEEN 25 AND 75

 UNIQUE_ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24

24行が選択されました.


実行計画
----------------------------------------------------------
Plan hash value: 2829086308

-----------------------------------------------------------------------------------
| Id  | Operation           | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |             |    50 |   612 |     8  (25)| 00:00:01 |
|   1 |  MINUS              |             |       |       |            |          |
|   2 |   SORT UNIQUE NOSORT|             |       |       |            |          |
|*  3 |    INDEX RANGE SCAN | TAB311_PK   |    50 |   300 |     3   (0)| 00:00:01 |
|   4 |   SORT UNIQUE NOSORT|             |       |       |            |          |
|*  5 |    INDEX RANGE SCAN | IX01_TAB312 |    52 |   312 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50)
   5 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75)


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          9  consistent gets
          0  physical reads
          0  redo size
        993  bytes sent via SQL*Net to client
         63  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         24  rows processed

では, 最後に, 19cでも実行計画という名のレントゲンを診ておきたいと思います.

SYS@orclcdb> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

MINUS ALLは未サポートなので, シンタックスエラーになります.

SCOTT@orcl> @day2
1  SELECT
2    num
3  FROM
4    groupa
5  MINUS ALL
6  SELECT
7    num
8  FROM
9*   groupb
MINUS ALL
    *
ERROR at line 5:
ORA-00928: missing SELECT keyword

以前からサポートされているMINUS, やはり, SORT UNIQUE操作が利用されています. 21cのMINUSとは異なる動きのあることが見えてきます.

1  SELECT
2    num
3  FROM
4    groupa
5  MINUS
6  SELECT
7    num
8  FROM
9*   groupb

     NUM
----------
       1
       5

Execution Plan
----------------------------------------------------------
Plan hash value: 2070324559

------------------------------------------------------------------------------
| Id  | Operation           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |        |     7 |    45 |     8  (25)| 00:00:01 |
|   1 |  MINUS              |        |       |       |            |          |
|   2 |   SORT UNIQUE       |        |     7 |    21 |     4  (25)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| GROUPA |     7 |    21 |     3   (0)| 00:00:01 |
|   4 |   SORT UNIQUE       |        |     8 |    24 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL| GROUPB |     8 |    24 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
        0  recursive calls
        0  db block gets
       12  consistent gets
        0  physical reads
        0  redo size
      599  bytes sent via SQL*Net to client
      421  bytes received via SQL*Net from client
        2  SQL*Net roundtrips to/from client
        2  sorts (memory)
        0  sorts (disk)
        2  rows processed

アドベントカレンダー, 今のところ順調だが, 25回分全てのネタを書き終わったわけではないので, 先はナゲーーーーーーーなーーーと, 遠ーーーくを見てるw

Day3の担当は, 私です. よろしくお願いしますw

では, また, 明日.

参考）

19c
UNION [ALL], INTERSECTおよびMINUS演算子

21c
The Set Operators

投稿日時 2022年12月 2日 (金) 00時00分チューニング, SQL, Opera, パフォーマンス, Advent Calendar, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2021年2月18日 (木)

MicrosoftのEdgeがChromium版Edgeでたので久々にブラウザベンチマーク

MicrosoftのEdgeがChromium版Edgeになって、なんとMac版もでたので久々に、古い　Mac Pro mid2012 Mojaveでベンチマークとってみた

対処対象ブラウザは、Safari / Firefox / Google Chrome / Microsoft Edge (Chromium版Edge) / Vivaldi / Opera を　JetStream2の総合値で比較

昔のBrowser Benchmarkのエントリー(古い順)
IEって遅いんだよー。ってことをあまり気にしてない方へ。 / 2010年

まだ、レガシーブラウザと戦うのですか... / 2013年

あれから１年.....あの恐怖が再びw / 2014年

Edgeも出たし、JetStreamも出たので久々にブラウザのベンチマーク / 2015年

JetStream2の結果(2021版は以下のとおり) Safariが少々良い結果を出していますが、Firefoxを除き、あまり差はなくなってますね。Firefox頑張れ？(WindowsでIE使いたいって方も少数派だと思うので今回はWindowsでの比較は略。気が向いたらやるかもしれませんがWindows BootCampで起動するMacBookしかないんだよなーw)

Safari

Firefox

Google Chrome

Microsoft Edge (Chromium版Edge)

Vivaldi

Opera

気軽に食べ歩きにいける世の中になってほしい。。。

投稿日時 2021年2月18日 (木) 21時08分 FAQ, Safari, FireFox, Opera, HTML5, パフォーマンス | 固定リンク | 0 | コメント (0)

2020年12月14日 (月)

標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の14日目です。

今回は大作（軽めにしたかったけど、少々難しのでそのまま載せることにしました）

業務上あまり多くないですが、一連番号の集合を作りたくなることがあります。シーケンスを使わずに。。

Oracleには昔から比較的簡単なクエリーで一連番号の集合を作り出せる（本来その目的のた目のクエリーではないですが）クエリーがいくつかあります。
PostgreSQLには、8.0(7.xぐらいから存在していたのか調べきれず。間違っていたらコメントいただけると助かります)ぐらいから集合を返す関数として、generate_series()が組み込まれています。
MySQLは調べた限りですが、その手の便利関数やクエリーはあまりなさそうでした。

でそれを救う救世主w　と言うのは大げさですが、WITH句を使った再帰問い合わせを使うと比較的互換の高い利用ができるようになってきました。
完全に同一構文ということではないのですけども。。。書き換える部分は少ない方だと思います：）

では、

Oracleから

まず、方言から古い順に紹介していきます。

Oracle/その1：階層問合せとlevel擬似列を利用する方法

他の方法に比べると処理時間なども有利ではあるのですが、Oracleだけでしか利用できない方法です。昔から利用している方は手グセでこちらをタイプすることも多いはずw
実行計画もシンプルで、Oracleで利用可能な方法の中では負荷は軽め（私が検証した範囲では）

階層問合せか、再帰問合せか、それが問題だ #2
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2011/01/2-8488.html

階層問合せ
https://docs.oracle.com/cd/F19136_01/sqlrf/Hierarchical-Queries.html#GUID-0118DF1D-B9A9-41EB-8556-C6E7D6A5A84E

ORACLE> set tab off
ORACLE> set linesize 300
ORACLE> r
 1  SELECT
 2    LEVEL AS r
 3  FROM
 4    dual
 5  CONNECT BY
 6    LEVEL <= 10
 7*

        R
----------
        1
        2
        3
        4
        5
        6
        7
        8
        9
       10

10 rows selected.
Elapsed: 00:00:00.10
ORACLE>ORACLE> set autot trace exp
ORACLE> r
...略...

Execution Plan
----------------------------------------------------------
Plan hash value: 1236776825

-----------------------------------------------------------------------------
| Id  | Operation                    | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |     1 |     2   (0)| 00:00:01 |
|*  1 |  CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   2 |   FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - filter(LEVEL<=10)

Oracle/その2：CUBEとrownum擬似列を利用する方法

これOracle 8iぐらいから拡張されたという記憶（間違ってたらごめんなさい）が、CUBEというクロス集計が簡単に書ける構文で長いクエリー書かなくて済むようになったーーーと
リリースされた当時は嬉しかった拡張の一つです。こんな使い方もできるのなーというところですが、実行計画を見るとかなり重めなんですよね。実際階層問合せより重いので、一連番号生成目的で利用することはほぼないですが、できるということで紹介しておきます。

20.3 CUBE(GROUP BYの拡張)
https://docs.oracle.com/cd/F19136_01/dwhsg/sql-aggregation-data-warehouses.html#GUID-C5FDD050-DCE0-4FE1-9741-420E2F970A36

ROWNUM疑似列
https://docs.oracle.com/cd/F19136_01/sqlrf/ROWNUM-Pseudocolumn.html#GUID-2E40EC12-3FCF-4A4F-B5F2-6BC669021726

ORACLE> r
  1  SELECT rownum
  2  FROM
  3  (
  4    SELECT 1
  5    FROM
  6      dual
  7    GROUP BY
  8      CUBE(1,1,1,1,1)
  9  )
 10  WHERE
 11*   rownum <= 10

    ROWNUM
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 rows selected.
Elapsed: 00:00:00.16

Execution Plan
----------------------------------------------------------
Plan hash value: 2264780677

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                     | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                              |                            |     1 |       |    66   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY                                |                            |       |       |            |          |
|   2 |   VIEW                                        |                            |     1 |       |    66   (0)| 00:00:01 |
|   3 |    TEMP TABLE TRANSFORMATION                  |                            |       |       |            |          |
|   4 |     MULTI-TABLE INSERT                        |                            |       |       |            |          |
|   5 |      SORT GROUP BY NOSORT ROLLUP              |                            |     1 |       |     2   (0)| 00:00:01 |
|   6 |       FAST DUAL                               |                            |     1 |       |     2   (0)| 00:00:01 |
|   7 |      DIRECT LOAD INTO (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D698E_276CE9B |       |       |            |          |
|   8 |      DIRECT LOAD INTO (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D698F_276CE9B |       |       |            |          |
|   9 |     VIEW                                      |                            |    32 |   416 |    64   (0)| 00:00:01 |
|  10 |      VIEW                                     |                            |    32 |   416 |    64   (0)| 00:00:01 |
|  11 |       UNION-ALL                               |                            |       |       |            |          |
|  12 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  13 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  14 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  15 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  16 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  17 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  18 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  19 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  20 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  21 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  22 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  23 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  24 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  25 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  26 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  27 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  28 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  29 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  30 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  31 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  32 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  33 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  34 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  35 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  36 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  37 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  38 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  39 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  40 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  41 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  42 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698E_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
|  43 |        TABLE ACCESS FULL                      | SYS_TEMP_0FD9D698F_276CE9B |     1 |    13 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(ROWNUM<=10)

Oracle/その3：再帰問合せを利用する方法

冒頭で紹介した階層問合せはOracleの方言ばりばりですが、階層問合せをサポートしているエンジンも多くなってきたこともあり、同一構文とまでは行きませんがかなり互換性は高い方法です。
汎用性のある方法にしたい場合は階層問合せを利用しておくと良いかもしれませんね。

Oracleの再帰問合せ構文では、recursive　がないのが大きな違いです。また、dual表の利用も必要なのでこの点が他のエンジンと違うところと思っておけば大丈夫だと思います。
意外と構文はシンプルです。階層問合せに比べるとタイプする文字列は多いですけどw

再帰的副問合せのファクタリング
https://docs.oracle.com/cd/F19136_01/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6

ORACLE> r
  1  WITH gen_nums(v)
  2  AS
  3  (
  4    SELECT 1
  5    FROM
  6      dual
  7    UNION ALL
  8    SELECT v + 1
  9    FROM
 10  gen_nums
 11    WHERE v + 1 <= 10
 12  )
 13  SELECT v from gen_nums
 14*

	 V
----------
	 1
	 2
	 3
	 4
	 5
	 6
	 7
	 8
	 9
	10

10 rows selected.
Elapsed: 00:00:00.16

Execution Plan
----------------------------------------------------------
Plan hash value: 1492144221

--------------------------------------------------------------------------------------------------
| Id  | Operation                                 | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                          |      |     2 |    26 |     4   (0)| 00:00:01 |
|   1 |  VIEW                                     |      |     2 |    26 |     4   (0)| 00:00:01 |
|   2 |   UNION ALL (RECURSIVE WITH) BREADTH FIRST|      |       |       |            |          |
|   3 |    FAST DUAL                              |      |     1 |       |     2   (0)| 00:00:01 |
|*  4 |    RECURSIVE WITH PUMP                    |      |       |       |            |          |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter("V"+1<=10)

MySQL

調べた限りですが、MySQLにはPostgreSQLのような集合を返す関数として、generate_series()関数やOracleのような多くの方言はなさそうで
MySQL8.0からサポートされた再帰問合せが利用できます。Oracleで紹介した3つめの方法です。

多少構文は異なりますが、違うのは dual表がないのとrecursiveが必要なところ（MySQLの場合dual表を利用することも可能なので差異はrecursiveだけにすることもできます）

Recursive Common Table Expressions
https://dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursive

mysql> WITH RECURSIVE gen_nums(v)
    -> AS
    -> (
    ->   SELECT 1
    ->   UNION ALL
    ->   SELECT v + 1
    ->   FROM
    ->     gen_nums
    ->   WHERE v + 1 <= 10
    -> )
    -> SELECT v from gen_nums;
+------+
| v    |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
|    6 |
|    7 |
|    8 |
|    9 |
|   10 |
+------+
10 rows in set (0.06 sec)

mysql> explain analyze WITH RECURSIVE gen_nums(v)
    -> AS
    -> (
    ->   SELECT 1
    ->   UNION ALL
    ->   SELECT v + 1
    ->   FROM
    ->     gen_nums
    ->   WHERE v + 1 <= 10
    -> )
    -> SELECT v from gen_nums;
+----------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                        |
+----------------------------------------------------------------------------------------------------------------+
| -> Table scan on gen_nums  (actual time=0.000..0.001 rows=10 loops=1)
    -> Materialize recursive CTE gen_nums  (actual time=0.019..0.020 rows=10 loops=1)
        -> Rows fetched before execution  (actual time=0.000..0.000 rows=1 loops=1)
        -> Repeat until convergence
            -> Filter: ((gen_nums.v + 1) <= 10)  (cost=2.73 rows=2) (actual time=0.002..0.003 rows=4 loops=2)
                -> Scan new records on gen_nums  (cost=2.73 rows=2) (actual time=0.001..0.001 rows=5 loops=2)
|
+----------------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)

さて、最後は、
PostgreSQL

PostgreSQL/その1：generate_series()関数を利用する方法

PostgreSQL方言の関数ですが、使いやすいですねタイプする文字数は一番少ない：）

9.24. 集合を返す関数 - 表9.61 連続値生成関数 - generate_series
https://www.postgresql.jp/document/12/html/functions-srf.html

postgresql=> SELECT r FROM generate_series(1, 10) r;
 r
----
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
(10 rows)

test=> explain (analyze,buffers,verbose) SELECT r FROM generate_series(1, 10) r;
                                                           QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
 Function Scan on pg_catalog.generate_series r  (cost=0.00..10.00 rows=1000 width=4) (actual time=0.007..0.008 rows=10 loops=1)
   Output: r
   Function Call: generate_series(1, 10)
 Planning Time: 0.025 ms
 Execution Time: 0.022 ms
(5 rows)

PostgreSQL/その2：再帰問合せを利用する方法

見ての通り、MySQLで利用した構文がそのまま利用できます。全体で見る再帰問合せを利用する方法がもっとも差異の少ないことがわかります。微妙なさなんですけどね。　無くせないものか。。そこw

7.8. WITH問い合わせ（共通テーブル式）
https://www.postgresql.jp/document/12/html/queries-with.html

postgresql=> WITH RECURSIVE gen_nums(v)
postgresql-> AS
postgresql-> (
postgresql(>   SELECT 1
postgresql(>   UNION ALL
postgresql(>   SELECT v + 1
postgresql(>   FROM
postgresql(>     gen_nums
postgresql(>   WHERE v + 1 <= 10
postgresql(> )
postgresql-> SELECT v from gen_nums;
 v
----
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
(10 rows)
postgresql=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v)
AS
(
  SELECT 1
  UNION ALL
  SELECT v + 1
  FROM
    gen_nums
  WHERE v + 1 <= 10
)
SELECT v from gen_nums;
                                                            QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
 CTE Scan on gen_nums  (cost=3.21..3.83 rows=31 width=4) (actual time=0.004..0.016 rows=10 loops=1)
   Output: gen_nums.v
   CTE gen_nums
     ->  Recursive Union  (cost=0.00..3.21 rows=31 width=4) (actual time=0.003..0.013 rows=10 loops=1)
           ->  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.002 rows=1 loops=1)
                 Output: 1
           ->  WorkTable Scan on gen_nums gen_nums_1  (cost=0.00..0.26 rows=3 width=4) (actual time=0.001..0.001 rows=1 loops=10)
                 Output: (gen_nums_1.v + 1)
                 Filter: ((gen_nums_1.v + 1) <= 10)
                 Rows Removed by Filter: 0
 Planning Time: 0.055 ms
 Execution Time: 0.039 ms
(12 rows)

ということで、今日は、役に立つような立たないような、でも何かの役に立ちそうなネタにしてみました。:)

投稿日時 2020年12月14日 (月) 01時18分 FAQ, SQL, Opera, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2015年11月21日 (土)

WITH clause in-line PL/SQL functionって....

12cの新機能でオイタをしてみたw

with句に関数仕込んで内部でSQL文を実行してオイタしてみました。

実際にこのような使い方するんでしょうか？
これをやるなら素直にスカラー副問合せの方がいいと思うんですね.....
（スカラー副問合せのように使われたら、同じく12cの新機能、Scalar subquery unnestingもできなし。）

なんでこんな機能必要なんだろう?
どのような場面で、有効なんだろう？

今の所、使いどころが思い浮かばないので、誰か教えて〜〜〜〜〜！　
とモヤモヤしてたんですが、今日はお留守番で時間だけはあったので、ごにょごにょとw

SCOTT> set serveroutput on
SCOTT> set feed off
SCOTT> r
  1   with
  2   	function hoge return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		for rec in (select empno,ename from emp order by empno) loop
  7   			dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****');
  8  		end loop;
  9  		return null;
 10   	end;
 11   select
 12   	hoge
 13   from
 14   	dual
 15   where
 16* 	hoge is not null

**** 7369:SMITH ****
**** 7499:ALLEN ****
**** 7521:WARD ****
**** 7566:JONES ****
**** 7654:MARTIN ****
**** 7698:BLAKE ****
**** 7782:CLARK ****
**** 7839:KING ****
**** 7844:TURNER ****
**** 7900:JAMES ****
**** 7902:FORD ****
**** 7934:MILLER ****

経過: 00:00:00.01

こんなことをやられると....
実行計画には現れないしw　（ちなみにスカラー副問合せは実行計画を見ただけでわかりますです。はい）

ただのチューナーいじめじゃ >< w
SQLトレースなら補足できるけど、なんぎじゃのう。げほげほ

(WITH句のインラインPL/SQLファンクション（名称あってるのかな？）内部でSQL文は実行しない方がいいと思うけど。。。。？？？)

SCOTT> 
SCOTT> set autot trace exp stat
SCOTT> r
  1   with
  2   	function hoge return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		for rec in (select empno,ename from emp order by empno) loop
  7   			dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****');
  8  		end loop;
  9  		return null;
 10   	end;
 11   select
 12   	hoge
 13   from
 14   	dual
 15   where
 16* 	hoge is not null

**** 7369:SMITH ****
**** 7499:ALLEN ****
**** 7521:WARD ****
**** 7566:JONES ****
**** 7654:MARTIN ****
**** 7698:BLAKE ****
**** 7782:CLARK ****
**** 7839:KING ****
**** 7844:TURNER ****
**** 7900:JAMES ****
**** 7902:FORD ****
**** 7934:MILLER ****

経過: 00:00:00.03

実行計画
----------------------------------------------------------
Plan hash value: 4034615273

-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|*  1 |  FILTER          |      |       |            |          |
|   2 |   FAST DUAL      |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("HOGE"() IS NOT NULL)


統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        363  bytes sent via SQL*Net to client
        541  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

WITH句のインラインPL/SQLファンクション内でのSQL文の実行はダークサイドな香りしかしないので、使うならデータの加工等、計算中心目的かねぇ〜。とマニュアル読んでたら見つけたw
　
(マニュアルのサンプルも加工のみ！ )

SCOTT> r
  1   with
  2   	function hoge(eno number) return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		dbms_output.put_line('Called');
  7  		return '**** '||eno||' ****';
  8   	end;
  9   select
 10   	hoge(empno)
 11   from
 12*  	emp

HOGE(EMPNO)
---------------------------------------------------------------------
**** 7369 ****
**** 7499 ****
**** 7521 ****
**** 7566 ****
**** 7654 ****
**** 7698 ****
**** 7782 ****
**** 7839 ****
**** 7844 ****
**** 7900 ****
**** 7902 ****
**** 7934 ****
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
経過: 00:00:00.02

Database SQL Language Reference (12.1)
Database SQL Language Reference (12.1) - SELECT

みなさん、ダークサイドに落ちないように注意しましょうね！ :)

投稿日時 2015年11月21日 (土) 15時32分 PL/SQL, チューニング, SQL, Opera, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年12月17日 (水)

机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！

予備プラン発動中 :)

ということで、諸事情により開け忘れた窓を開けるためJPOUG Advent Calendar 2014 ２回目の登場となりました。

JPOUG Advent Calendar 2014 17日目のエントリーです。

突然ですが、

「机上SQLチューーーーーニング、クイズ〜〜〜っ！！！！！！
　駆動表（外部表）はどれだ！！！！」

なお、このクイズには次の制限があります。

別途、本ブログで解答エントリーが公開（年明けを予定）されるまで、Oracle Databaseを利用して答え求めるのは禁止。 :-)
Oracle Databaseを利用せず、机上で、どの表を駆動表（外部表）にすれば理想的な実行計画になりそうか考えてみてね。

また、解答はOracle Database 12c Release 1 12.1.0.2.0 のオプティマイザをインストールしたまま（初期化パラメータはデフォルトのまま）の環境を使って行います。
（11gでも違わないと思いますが)

というクリスマスプレゼント :)

次に示されるSQL文の駆動表（外部表）はどれでしょうか？　

前提

統計情報と実データとの間に乖離はありません。
リテラル値で指定した検索条件に該当するデータは必ず存在します。

※引っ掛け問題もあるよ！　:)

問題１
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引
create table a1 (
    id number primary key
    , data varchar2(1000)
) nologging
/
create table a2 (
    id number primary key
    , data varchar2(1000)
) nologging
/

統計情報
TABLE_NAME     INDEX_NAME       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
A1             SYS_C0010377        10000         10000               295
A2             SYS_C0010378         2000          2000                59

SELECT
	/* SQL01 */
	/*+
		MONITOR
		USE_NL(a1 a2)
	*/
	*
FROM
	a1	
	INNER JOIN a2
	ON
		a1.id = a2.id
WHERE
	a1.id BETWEEN 1 AND 100
/

問題２
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題１と同じです。)

SELECT
	/* SQL02 */
	/*+
		MONITOR
		USE_HASH(a1 a2)
	*/
	*
FROM
	a1
	INNER JOIN a2
	ON
		a1.id = a2.id
/

問題３
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
なお、D1とD2の多重度は、D1:D2 = 1:100
(個人的にUMLの多重度表記のほうが好きなので、UML表記の多重度で記述します。）

表と索引
create table d1 (
    id number
    , data varchar2(1000)
) nologging
/
alter table d1 add constraint pk_d1 primary key (id) using index nologging
/
create table d2 (
    id number not null
    , seq# number not null
    , data varchar2(1000)
) nologging
/
alter table d2 add constraint pk_d2 primary key (id, seq#) using index nologging
/

統計情報
TABLE_NAME     INDEX_NAME       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
D1             PK_D1                 200           200                 9
D2             PK_D2               20000         20000               870

SELECT
    /* SQL03 */
    /*+
        MONITOR
    */
    *
FROM
	d2
WHERE
    EXISTS (
        SELECT 
            1
        FROM
            d1
        WHERE
            d1.id = d2.id
            AND d1.id IN (1,5)
    )
/

問題４
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題３と同じです。)

SELECT
    /* SQL04 */
    /*+
        MONITOR
    */
    *
FROM
    d1
    INNER JOIN d2
    ON
        d1.id > d2.id
        AND d2.id BETWEEN 1 AND 5
        AND d2.seq# BETWEEN 2 AND 4
/

問題５
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引定義
create table b1 (
    id number
    , data varchar2(1000)
) nologging
/
alter table b1 add constraint pk_b1 primary key(id) using index nologging
/
create table b3 (
    id number
    , seq# number
    , data varchar2(1000)
) nologging
/
alter table b3 add constraint pk_b3 primary key (id, seq#) using index nologging
/
create table b2 (
    id number
    , seq# number
    , subseq# number
    , data varchar2(1000)
) nologging
/
alter table b2 add constraint pk_b2 primary key (id ,seq#, subseq#) using index nologging
/

統計情報
TABLE_NAME     INDEX_NAME       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
B1             PK_B1               20000         20000               870
B2             PK_B2                5000          5000               228
B3             PK_B3                 500           500                23

ERDと多重度
b1 : b3 = 1 : 0..2
b3 : b2 = 1 : 0..10
(UML表記の多重度で記述しています。）


SELECT
    /* SQL05 */
    /*+
        MONITOR
        USE_HASH(b1 b3 b2)
    */
    *
FROM
    b1
    INNER JOIN b3
    ON
        b1.id = b3.id
    INNER JOIN b2
    ON
        b3.id = b2.id
        AND b3.seq# = b2.seq#
/

問題６
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題５と同じです。)

SELECT
    /* SQL06 */
    /*+
        MONITOR
        USE_HASH(b1 b3 b2)
    */
    *
FROM
    b1
    LEFT OUTER JOIN b3
    ON
        b1.id = b3.id
    LEFT OUTER JOIN b2
    ON
        b3.id = b2.id
        AND b3.seq# = b2.seq#
/

冬休みの宿題〜〜〜〜っ。暇つぶしにトライしてみてくださいね。（ニヤニヤ　

解答エントリーの公開は年明けを予定していま〜す。

We wish your merry christmas and a happy new year!

次の扉は、Tamie Yamamotoさんです。

投稿日時 2014年12月17日 (水) 00時10分チューニング, SQL, Opera, JPOUG, Oracle Database 12c release 1, Advent Calendar | 固定リンク | 0 | コメント (0) | トラックバック (0)

2011年8月14日 (日)

Macユーザ増えたよな〜 :) とアクセスログ見て

このブログを書き始めたころは、タイトルとは裏腹にWindowsとかIEからのアクセスが多かったのですが、ここ１、２年でずいぶん変ってきたな〜、とか、IEの減りっぷりって凄いとか思いながらアクセスログみてると思います。

次のグラフは当ブログのアクログからIEの世代交替状況を見たものです。来年はどうなってるか楽しみですねー。さすがにIE10はまだありませんが、IE7など以前のはとっとと消えてほしいですね。

次のグラフは、当ブログを参照しているブラウザの種類（バージョンに関係なく）でまとめたものです。
IEの減りっぷりは見事というか、IE9の出遅れ感が強いだけで、これからIE10とかで盛り返してくるのか見物ですね〜。ただIE6/7/8使っているところって大人の事情で金縛り状態のところが多いから切り替わるためには１、２年のタイムラグはありそうな気がします。　だって昨年でさえ、IE6/7対応縛りでjavascriptがおそーいとか無茶やってるとこ多数あったしw

最後のグラフは、OS別（バージョンに関係なく）でまとめたものです。
いろいろな勉強会とか参加してて特にここ２、３年で随分Macユーザ増えましたよねー、ほんと。
以前はWindowノートが半分以上だったところでも、最近MBAだらけとかいうとこ多いっす。

投稿日時 2011年8月14日 (日) 16時00分 Mac, アクセスログ, Linux, Windows, iPhone, Safari, FireFox, Opera | 固定リンク | 0 | コメント (0) | トラックバック (0)

2011年2月 8日 (火)

shutdown immeidateしない、ほかの理由に遭遇！

別途検証して別エントリにする予定だけど（遠征先で時間ないので…）、この状態でshutdown immeidateが待機するとshutdown timeoutしないというのも特徴みたい…

Oracleのバージョンは11g R2 11.2.0.1.0 for Linux (32bit)だけどUnix/Linux系なら発生するよ、きっと。

そういえば、以前こんなエントリ書いてましたっけ「shutdown timeout」

では、早速再現テスト。

まず、SQL*Plusを起動、SYSユーザに接続してOracleインスタンスを起動します…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:46:11 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

00:46:11 > conn / as sysdba
アイドル・インスタンスに接続しました。
00:46:16 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             373295488 bytes
Database Buffers           41943040 bytes
Redo Buffers                6094848 bytes
データベースがマウントされました。
データベースがオープンされました。
00:47:17 SYS>

別端末でSQL*Plusを起動してSYSTEMユーザまたはSYSユーザに接続.
(別途詳しく検証する予定だけど、今のところSYSTEM/SYSユーザ以外では発生してないので）

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:50:18 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

00:50:18 > conn system
パスワードを入力してください: 
接続されました。
00:50:23 SYSTEM>

次にOracleを起動したSQL*PlusのSYSユーザでshutdown immeidateを発行する…

00:51:22 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
00:51:34 SYS>

この状態だとOracleインスタンスは正常にshutdown immeidateで停止できる。あたりまえだけど。

では、再現テストですよん。

では次のパターンはどうか？

前述した手順と同じく、SYSで接続してOracleインスタンスを起動する…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:54:47 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

00:54:47 > conn / as sysdba
アイドル・インスタンスに接続しました。
00:54:52 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             373295488 bytes
Database Buffers           41943040 bytes
Redo Buffers                6094848 bytes
データベースがマウントされました。
データベースがオープンされました。
00:55:46 SYS>

前述した手順と同様に、別端末でSQL*Plusを起動し、SYSTEMユーザ(SYSユーザでもいいよ）へ接続する。
さらに、! (SQL*Plusのhost command）でshellに入っておく…。ここがポイント

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 01:01:42 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$

shutdow immeidateの待機を再現させますよー、Oracleインスタンスを起動したSQL*PlusのSYSユーザでshutdown immeidate文を発行する…

01:03:04 SYS> 
01:03:05 SYS> shutdown immediate

いつまでたってもOracleインスタンスは停止しない。この例では載せていないがマニュアルに記載されているshutdown timeoutも１時間たっても２時間たっても発生しないようだ…（別途検証予定）

アラートログを確認してみると…５分毎に、”SHUTDOWN: Active processes prevent shutdown operation”というログを出力し続けてる…

Tue Feb 08 01:03:07 2011
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC
Stopping background process MMNL
Stopping background process MMON
License high water mark = 2
All dispatchers and shared servers shutdown
Tue Feb 08 01:08:17 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:13:24 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:18:31 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:23:37 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:28:43 2011
SHUTDOWN: Active processes prevent shutdown operation

プロセスのトレースファイルで最新のものでファイルサイズが増えつつけているものがある…
tailでのぞいてみると…

PID=3542のOSプロセスをkillできずにループしているように見える…

[oracle@leaffish trace]$ ll -lrt

・・・中略・・・

-rw-r----- 1 oracle oinstall      61  2月  8 01:00 discus_mman_3483.trm
-rw-r----- 1 oracle oinstall     863  2月  8 01:00 discus_mman_3483.trc
-rw-r----- 1 oracle oinstall      61  2月  8 01:00 discus_dbrm_3477.trm
-rw-r----- 1 oracle oinstall     904  2月  8 01:00 discus_dbrm_3477.trc
-rw-r----- 1 oracle oinstall      45  2月  8 01:01 discus_ora_3539.trm
-rw-r----- 1 oracle oinstall     669  2月  8 01:01 discus_ora_3539.trc
-rw-r----- 1 oracle oinstall  235323  2月  8 01:08 alert_discus.log
-rw-r----- 1 oracle oinstall    6420  2月  8 01:12 discus_ora_3513.trm
-rw-r----- 1 oracle oinstall   60565  2月  8 01:12 discus_ora_3513.trc
[oracle@leaffish trace]$ 
[oracle@leaffish trace]$ tail -f discus_ora_3513.trc
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:15.641
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:16.663
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:17.678
ksukia: Starting kill, flags = 1
ksukia: Attempt 119 to re-kill process OS PID=3542.
ksukia: killed 1 out of 1 processes.

*** 2011-02-08 01:13:18.699
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:19.709
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:20.735
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:21.750
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:22.756
ksukia: Starting kill, flags = 1
ksukia: Attempt 120 to re-kill process OS PID=3542.
ksukia: killed 1 out of 1 processes.

*** 2011-02-08 01:13:23.779
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:24.790
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:25.821
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

[oracle@leaffish trace]$

killできないと繰り返しログに吐かれているプロセス　PID=3542とは何者？…
psとpstreeコマンドでみてみると…

SQL*Plusの!(host command)でshellに入る生成されるプロセスらしい…、このプロセスSYSTEMユーザやSYSユーザ以外接続している場合はなぜか今のところ生成されいないように見える…

この<defunct>なプロセスは何屋さん？　shutdown immediateをimmediateじゃない状態にするのは大量のundoデータだけじゃないのね〜＞＜

それもSQL*Plusの!(host command）は便利なので、私も多用していまして、ついつい、SQL*Plusに接続して、!でshellに入って、SQL*Plusから入ったのを忘れてさらに、SQL*Plus起動して、！でshellに入って…なんてことやってしまうことは多々あります。＞＜

これが原因で、shutdown immeidateが待機させられるなんて〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜＞＜。

[oracle@leaffish ˜]$ ps -ef | grep 3542
oracle    3542  3541  0 01:01 ?        00:00:00 [oracle] <defunct>
oracle    3785  3056  0 01:24 pts/5    00:00:00 grep 3542
[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ pstree -up oracle

・・・中略・・・

gnome-terminal(2806)─┬─bash(2812)───sqlplus(3398)───oracle(3513)
                     ├─bash(2909)───tail(3055)
                     ├─bash(2937)
                     ├─bash(3031)───sqlplus(3541)─┬─bash(3543)
                     │                            └─oracle(3542)
                     ├─bash(3056)───pstree(3772)
                     ├─gnome-pty-helpe(2811)
                     └─{gnome-terminal}(2813)

・・・以下略・・・

もう少し検証してみましょう！　

shellからだけexitしてみるも……Oracleはまだ停止しない…

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$ exit
exit

01:30:56 SYSTEM>

じゃ、SQL*Plusからもexitしよう

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$ exit
exit

01:30:56 SYSTEM> exit
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsとの接続が切断されました。
[oracle@leaffish ˜]$

次の瞬間……

データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
01:32:10 SYS>

なんだと〜〜〜〜〜〜〜〜。いつからこーなんだー。　怖くてSQL*Plusから!(host command)でshellに入れないじゃないか〜〜〜＞＜

次回へつづく。

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！おまけ

投稿日時 2011年2月 8日 (火) 07時04分 Linux, Oracle Database 11g, Mac(Intel x86), Opera, Oracle11g R2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2010年5月31日 (月)

IEって遅いんだよー。ってことをあまり気にしてない方へ。

speed/validity selectors test for frameworks.っていう有名なサイトがあるんだけど、具体的にどのぐらいの差になんの？　なんてあまり情報が載ってるところはないので自分で確認できる範囲で新旧CPUとブラウザで比較してみました。なにかの参考になるとは思います。jQueryでだけですけどね。

IE6/7のデータを載せてないのですが、jQuery1.2.6（Slicktestのオリジナルでテストされてるやつね）で、他のプラウザと処理結果の違うところがいくつか発生するので載せるかどうか考えてるところ。注釈付きで載せるかな〜。まあ、IE8ですらこの遅さだからIE6/7はもっと遅いんだけどね。　2010/5/31追記
8-Jun-2010:Safari5及びChrome5リリースされたのでデータ追記。また、Safari5はMacOS X 10.5以上でリリースされたためMacOS X 10.4では同時期のWebkitで計測したでたを追加
9-Jun-2010:MacOS X 10.6.3/Chrome5.0.375.70にアップデートされたので結果を追加。
9-Jun-2010:Intel MacOS X Safari5がインストール直後にSafari4より遅かったが、cacheクリア、resetで早くなったので追記

注）各ブラウザで同テストを１０回実行して、最大値、最小値を除いた平均値を載せてあります。

CPU毎にいろいろなブラウザでSlickSpeed TestのjQueryのライブラリを1.3以降にして比較してみた。
IEは8.0でもダントツで遅いのがはっきり分かりますね。またOSの影響よりCPUのクロック数での違いが大きい事も分かりますよね。
1CPUのクロック数が早いほうが処理速度がいいって結果からも分かります。実際、Windowsだと、IEでテスト中にタスクマネージャを見ると１CPUが100%になるのが確認できますよー。（ネタが集まったらまた情報を載せる予定。）

CPU/OS	Version	jQuery1.3.2	jQuery1.4.2
Intel Core2 Duo 2Ghz / WindowsXP	4.0.5	36ms	43ms
	3.6.3	61ms	80ms
	10.52	50ms	50ms
	8.0	277ms	375ms
IBM PowerPC G4 1Ghz / MacOS X 10.5.8	4.0.5	102ms	148ms
	5.0	81ms	99ms
	3.6.3	139ms	131ms
	10.52	127ms	124ms
Intel Core2 duo 2.2Ghz / MacOS X 10.6.3	4.0.5	35ms	44ms
	5.0 (6533.16) Install直後	40ms	49ms
	5.0 (6533.16) clear cache and reset後	34ms	38ms
	5.0beta	39ms	40ms
	5.0.375.55	49ms	47ms
	5.0.375.70	39ms	38ms
	3.6.3	63ms	63ms
	10.52	57ms	54ms
IBM PowerPC G5 2.7Ghz / MacOS X 10.4.11	4.0.5	42ms	54ms
	Webkit r60742(5-Jun)	38ms	43ms
	3.6.3	52ms	48ms
	10.52	45ms	46ms
AMD Athlon XP 2200+ / Windows XP	4.0.5	96ms	114ms
	5.0	85ms	110ms
	4.1	64ms	60ms
	5.0	67ms	66ms
	3.6.3	95ms	95ms
	10.52	65ms	63ms
	8.0	255ms	238ms
AMD Athlon MP 2800+ / Windows XP	4.0.5	73ms	89ms
	5.0	68ms	84ms
	4.1	49ms	46ms
	5.0	47ms	45ms
	3.6.3	73ms	72ms
	10.52	56ms	53ms
	8.0	240ms	255ms
Intel Pentium M 1Ghz / CentOS 5.4	3.6.3	101ms	100ms
Intel Pentium M 1Ghz / CentOS 5.4	10.10	118ms	117ms

投稿日時 2010年5月31日 (月) 19時58分 Mac, Linux, Windows, Mac(Intel x86), Open Source, Safari, Opera, JavaScript | 固定リンク | 0 | コメント (0) | トラックバック (0)

2009年9月 2日 (水)

Opera 10（正式版）で改善されたOpera 10 betaでのtext-shadow表示問題

Safari4.0とFireFox3.5とOpera 10 Beta　で　text-shadowというタイトルで書いたことがあったが、Opera10が正式リリースされたので前回問題だったtext-shadowの表示を再確認。
結果としては改善されたようでめでたしめでたし。。

Opera 10 betaでのtext-shadowの表示。（text-shadow:1px 2px 3px grayの表示)

Opera 10（正式版）でのtext-shadowの表示。（text-shadow:1px 2px 3px grayの表示)。
改善されてます！！！　;)

投稿日時 2009年9月 2日 (水) 23時24分 Mac, Mac(Intel x86), Opera | 固定リンク | 0 | コメント (0) | トラックバック (0)

2009年7月 1日 (水)

Safari4.0とFireFox3.5とOpera 10 Beta　で　text-shadow

いままでtext-shadowをサポートしているブラウザはSafariだけだったけど、FireFox3.5やOpera 10 betaでもサポートしてくれたんですね。ということで現時点での比較。

Safari 4.0 (Build4530.17)
いつも見慣れたstyle="text-shadow:1px 2px 3px gray"は以下のように表示される。

本日リリースされたばかりのFireFox 3.5
Safari4.0と比べても違和感なし。:)

最後にOpera 10 Beta
見ての通りかなり強烈。目が疲れる。Beta版だからな〜ということで正式リリース時にはなんとかしてくれるのでしょうね。多分。

投稿日時 2009年7月 1日 (水) 08時36分 Mac, Mac(Intel x86), Safari, FireFox, Opera | 固定リンク | 0 | コメント (0) | トラックバック (0)

Mac De Oracle

MacOS X で動作する Oracle　が正式にリリースされたのだ！ 1996年にリリースされた、Personal Oracle7 for MacOS以来、封印されていたMacOS版が、（2005年）９年ぶりに正式リリースされたのでいろいろあそんでみたくなった！