オラクる。

oracle専門ブログにしてみようかな~っと

2016年06月

Oracle Restartを12cで構成してみます。
非推奨になるという噂だけど・・・

000015

まずは、Gridのインストールから
runInstallerでインストーラーを起動します。

000016

「スタンドアロン・サーバー用に~」を選択します。
ここ重要です。

000017

言語を選択します。

000018

ASMを利用するので新しくドライブグループを作成します。

000019

検出パスを/dev/sd*に変更します。

000020

ドライブが表示されました。
今回は2つ選択しています。

000021

ASMの新しいパスワードを設定します。

000022

Enterprise Manage gridへの登録は行ないません。

000023

事前に作成したasmグループを選択します。

000024

インストール先を選択します。

000025

インベントリを選択します。

000026

12cから事前にrootパスワードを設定することで、rootスクリプトが自動実行されます。

000027

前提条件をチェックして

000028

いざインストール開始です。

000029

インストール中・・・

000031

インストールが完了しました。

[root@DB01 ~]# /u01/app/grid/product/12.1.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details     
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       db01                     STABLE
ora.LISTENER.lsnr
               ONLINE  ONLINE       db01                     STABLE
ora.asm
               ONLINE  ONLINE       db01                     Started,STABLE
ora.ons
               OFFLINE OFFLINE      db01                     STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       db01                     STABLE
ora.diskmon
      1        OFFLINE OFFLINE                               STABLE
ora.evmd
      1        ONLINE  ONLINE       db01                     STABLE
--------------------------------------------------------------------------------


コンソールからcrsctl stat res -tの結果を確認しました。
1台だけのgrid環境、出来上がりです。

次回も続きます。

列の並び順の違いによる、表の挙動の違いに関して確認してみます。

col COLUMN_NAME for a8
col TAB13_1 for a8
col TAB13_2 for a8
select T1.COLUMN_ID, T1.COLUMN_NAME "TAB13_1", T2.COLUMN_NAME "TAB13_2"
  from (select COLUMN_ID, COLUMN_NAME from USER_TAB_COLUMNS where TABLE_NAME='TAB13_1') T1,
       (select COLUMN_ID, COLUMN_NAME from USER_TAB_COLUMNS where TABLE_NAME='TAB13_2') T2
 where T1.COLUMN_ID = T2.COLUMN_ID order by 1 ;

 COLUMN_ID TAB13_1  TAB13_2
---------- -------- --------
         1 COL001   COL001
         2 COL002   COL100
         3 COL003   COL200
         4 COL004   COL300
         5 COL005   COL400
         6 COL006   COL500
         7 COL007   COL600
         8 COL008   COL700
         9 COL009   COL800
        10 COL010   COL900
        11 COL011   COL002
        12 COL012   COL003



       895 COL895   COL894
       896 COL896   COL895
       897 COL897   COL896
       898 COL898   COL897
       899 COL899   COL898
       900 COL900   COL899


今回、COL001~COL900が順番に並んでいるTAB1と、COL1の後にCOL100、COL200、COL300~COL900と続き、残りの数字は順番に並んでいるTAB2があったとします。
列の並び以外は一緒です。

insert into TAB13_1(COL001,COL100,COL200,COL300,COL400,COL500,COL600,COL700,COL800,COL900)
select LEVEL,'a','b','c','d','e','f','g','h','i'
from DUAL connect by LEVEL <=1000 ;
commit;

insert into TAB13_2(COL001,COL100,COL200,COL300,COL400,COL500,COL600,COL700,COL800,COL900)
select LEVEL,'a','b','c','d','e','f','g','h','i'
from DUAL connect by LEVEL <=1000 ;
commit;


TAB1とTAB2で全く同じ内容のINSERT文を発行します。
1000件のデータが挿入されます。

col SEGMENT_NAME for a16
select SEGMENT_NAME, BYTES/1024 from USER_SEGMENTS ;

SEGMENT_NAME     BYTES/1024
---------------- ----------
TAB13_1                2048
TAB13_2                 128
PK_TBL13_1               64
PK_TBL13_2               64


全く同じ内容のデータが挿入されたにも関わらず、表のサイズは全く違います。
これは列の並び順が違うことによるものです。
COL100、COL200~COL900はTAB2は先頭にあるのに対してTAB1は分散して存在します。
この場合、TAB1はそれぞれの列の間にNULLが入り、それがサイズになります。
しかし、TAB2の場合には後ろの列に空きがあるため。NULLは入りません。
ここが差異になります。

SQL> set timing on
SQL> update TAB13_1 set COL899 = 'hoge';
経過: 00:00:00.04
SQL> commit;
経過: 00:00:00.01
SQL>

SQL> update TAB13_2 set COL899 = 'hoge';
経過: 00:00:00.10
SQL> commit;
経過: 00:00:00.00

さらに、COL899にデータをセットします。
TAB2のUPDATEの方が少しだけ時間がかかっています。

SQL> analyze table TAB13_1 list chained rows ;
SQL> analyze table TAB13_2 list chained rows ;

SQL> select TABLE_NAME, count(HEAD_ROWID) from CHAINED_ROWS group by TABLE_NAME ;

TABLE_NAME                     COUNT(HEAD_ROWID)
------------------------------ -----------------
TAB13_2                                     1000


同じSQLを実行したのに行連鎖はTAB2にしか発生していません。
これはTAB2にとっては、COL899は一番後ろの列なので、COL888より前の全ての列にNULLがセットされます。
これがサイズ増、行連鎖発生の原因です。

SQL> select SEGMENT_NAME, BYTES/1024 from USER_SEGMENTS ;

SEGMENT_NAME     BYTES/1024
---------------- ----------
TAB13_1                2048
TAB13_2                2048

セグメントのサイズも結局一緒になっています。

20160616_033100259_iOS

本日は東京タワー近くで打ち合わせ
やっぱり東京タワーも壮大だな~
真下から眺めるとそれが実感できます
そして、お昼はこの近くで行ってみよう
ちょっと探して、気になったラーメン屋さんに入店
事前調査は一切無しで入ってみました
店員は一名で先客は5、6名ほど
店内はカウンターのみで、結構狭いです
クーラー効いてないから、ちょっと蒸し暑いな~(-_-;)

さて、メニューはシンプルに醤油、味噌、塩、そして田舎、鉄火という名前だけではわからないのも
ただ最初なのでオーソドックスに味噌をチョイス
ちょっと気難しそうな店主は、独特な声色でオーダーを繰り返します
店内を流れるラジオを聞きながら10分ほど
お待ちかねのラーメンの出来上がりです
ちょっと焦げ目の入ったチャーシューが食欲をそそります
そして、見た目は私が以前食べた旭川ラーメンに近いように思います
早速、いただくこととしましょう

スープはちょっと塩辛い味噌
出汁の風味がしっかりと効いています
麺は縮れ麺で、スープとの相性も抜群です
焦げ目の入ったチャーシューはとても柔らかく、焦げ目の部分が非常に香ばしい
たっぷりのネギ、味の染みたメンマ、ゆで卵がいいアクセントです
量は私にとっては控えめで大盛りでもよかったかな
最後にはライスも入れたくなった一品でした

食べ終わったら丼をカウンターに上げて、会計します
午後の仕事に向けてパワーチャージが出来ました
「ごちそうさま」



関連ランキング:ラーメン | 神谷町駅赤羽橋駅六本木一丁目駅

20160614_021909037_iOS

蒲田!と言えば?
とんかつ?ラーメン?
色々とあると思うけど、やっぱり一番は餃子
餃子を食べなきゃ蒲田を語れない
それぐらい、蒲田=餃子のイメージは強いです
しかも、蒲田は羽付き餃子発祥の地でもあるんですよ

そんな餃子の蒲田で餃子の超有名店「你好(ニイハオ)」に行ってきました
ここが「元祖」羽付き餃子のお店らしいですよ
きっと歴史があるのでしょう
きっと美味しいのでしょう

訪問は平日の11時
なので、待たずに入店
店内は広く、先客は4組ほど
声の高い、中国人の女性店員にオーダーを伝えます
オーソドックスにチャーハン+餃子のセット
10分ほど待って提供された品はチャーハンも餃子もボリュームたっぷり
餃子にはしっかりと羽が付いています

チャーハンはパラパラでシンプルな味付の一品
シンプルと言っても悪い意味ではなく、これぞ王道!と言った感じのチャーハン
餃子は羽の部分のパリパリな食感が素晴らしい
羽だけ食べても、しっかりと味がしていて、美味なのです
中の肉はジューシーで、噛んだ瞬間に溢れる肉汁!!
その肉汁を白いご飯の上にかけたら、きっとご飯が進むのだろう・・・
そんな餃子は醤油無しでも全然イケるぐらいです( ̄ー ̄)bグッ!

「蒲田 餃子」の実力を思う存分感じられました
蒲田に来たら、まずはここ!と言っても過言ではないでしょう

では、ごちそうさまでした



関連ランキング:中華料理 | 蒲田駅蓮沼駅京急蒲田駅

insert into TAB12_2 values(1, rpad('4KB_', 4000, '*'), null) ;
insert into TAB12_2 values(2, rpad('4KB_', 4000, '*'), rpad('4KB_', 4000, '*')) ;
commit;


4000バイトの列を2つ持つテーブルに対してデータを挿入します。
一つ目のデータは4000バイトのデータを1件、二つ目は2件

SQL> analyze table TAB1_2 list chained rows ;

表が分析されました。

SQL> select HEAD_ROWID, COL1, substr(COL2, 1, 8), substr(COL3, 1, 8)
  2  from TAB1_2 a, CHAINED_ROWS b
  3  where a.ROWID = b.HEAD_ROWID ;

HEAD_ROWID               COL1 SUBSTR(COL2,1,8)                 SUBSTR(COL3,1,8)
------------------ ---------- -------------------------------- --------------------------------
AAATkbAAAAAAACUAAA          2 4KB_****                         4KB_****


analyse文で分析を実行します。
1件、行連鎖が発生しています。
先ほど、4000バイトのデータを2件挿入したため、4K+4K+αで8Kのブロックが溢れたためです。

SQL> update TAB1_3 set COL255='hoge' where COL001=0 ;

1行が更新されました。

SQL> commit;

コミットが完了しました。

SQL> analyze table TAB1_3 list chained rows ;

表が分析されました。

SQL> select TABLE_NAME, HEAD_ROWID from CHAINED_ROWS where TABLE_NAME='TAB1_3';

レコードが選択されませんでした。

今度は列を256個持つテーブルです。
1列目のデータを更新します。
行移行は発生していません。

SQL> update TAB1_3 set COL256='hoge' where COL001=0 ;

1行が更新されました。

SQL> commit;

コミットが完了しました。

SQL> analyze table TAB1_3 list chained rows ;

表が分析されました。

SQL> select TABLE_NAME, HEAD_ROWID from CHAINED_ROWS where TABLE_NAME='TAB1_3';

TABLE_NAME                     HEAD_ROWID
------------------------------ ------------------
TAB1_3                         AAATkdAAAAAAACnAAA


今度は256列目のデータを更新してみます。
今度は行移行が発生したようです。
同じテーブルなのに更新する場所によって、行移行、行連鎖が発生します。
それは次回にでも

このページのトップヘ