buffer busy wait一例
阿新 • • 發佈：2018-06-17
架構 導致 inf 單位 AR dbm 測試 assm 分配
一張記錄用戶登錄退出的表，每天9點會突然慢一下，等待事件為buffer busy wait並發插入量為230左右。oracle使用assm(如圖)也就是L3,L2,L1架構理論上100個L1每個L1管理64個塊就支持6400並發，實際也是如此嗎？
進行插入實驗發現，插入都是插入到1個分區裏面，我們知道分區是一個接一個分配的，因為還沒分配到分區所以才導致插到1個分區裏，手動分配好多個分區。不幸的是結果還是一樣。
插入實驗一：
SQL> create table ye (id int,name char(10)) tablespace ye; Table created. [oracle]$cat insert.sh sqlplus/ as sysdba<<EOF insert into ye values($1,‘qqqq‘); commit; exec dbms_lock.sleep(100000) #防止pid不變導致插入同一個數據塊 EOF [oracle]$./insert.sh 1& [oracle]$./insert.sh 2& [oracle]$./insert.sh 3& [oracle]$./insert.sh 4& SQL> / ID FNO BLOCKID ROW_ID ---------- ---------- ---------- ---------- 18 161 0 2 8 171 0 1 8 172 0 3 8 172 1 3 8 178 0 4 8 181 0 5 8 184 0 2 8 185 0 6 8 186 0 7 8 187 0 8 8 188 0 9 8 189 0 10 8 190 0
插入實驗二：
SQL> / ID FNO BLOCKID ROW_ID ---------- ---------- ---------- ---------- 118 132 0 66 8 132 1 12 8 133 0 67 8 133 1 12 8 134 0 68 8 134 1 12 8 135 0 69 8 135 1 12 8 136 0 70 8 136 1 13 8 137 0 14 8 138 0 15 8 139 0 16 8 140 0 17 8 141 0 18 8 142 0 19 8 143 0 20 8 144 0 21 8 145 0 22 8 146 0 23 8 147 0 24 8 148 0 25 8 149 0 25 8 150 0 26 8 151 0 27 8 152 0 28 8 153 0 29 8 154 0 30 8 155 0 31 8 156 0 32 8 157 0 33 8 158 0 34 8 159 0 35 8 160 0 1 8 161 0 36 8 161 1 37 8 162 0 38 8 163 0 39 8 164 0 40 8 165 0 4 8 166 0 41 8 167 0 42 8 168 0 43 8 169 0 44 8 170 0 2 8 171 0 45 8 171 1 1 8 172 0 3 8 172 1 46 8 172 2 47 8 173 0 48 8 174 0 49 8 175 0 50 8 176 0 51 8 177 0 3 8 178 0 52 8 178 1 53 8 179 0 54 8 180 0 4 8 181 0 55 8 181 1 56 8 182 0 57 8 183 0 5 8 184 0 58 8 184 1 2 8 185 0 59 8 185 1 6 8 186 0 60 8 186 1 7 8 187 0 61 8 187 1 8 8 188 0 62 8 188 1 9 8 189 0 63 8 189 1 10 8 190 0 63 8 190 1 11 8 191 0 65 8 191 1 79 rows selected.
在進行70次插入發現，block到191之後開始重新向132號塊插入了，這也就能解釋128,129號塊為L1,130是L2,131是L3，128-191，64個塊的同時插入不夠230並發量所以有些塊在插入過程中又有新的會話要插入，所以導致了buffer busy wait，那麽為什麽只插入前64個塊呢？此時可以dump下131號段頭塊，可以看到前10位為文件號，後面為塊地址，正好看到是192號塊。插入的時候都是插入到高水位線以下，因此都插到了前64個塊。解決方法就是拉高水位線，每天先使用append方式插入數據再刪除，結果等待消失。
在總結下，如果塊是8K，區大小是1M，高水位就是一64個塊為單位依次往後挪，但是每次並發插入其實都只是往64個塊插入。
這裏還有個問題L1管理64個塊是固定的麽？
SQL> create table tbs(id int ,name char(10)) tablespace ye1; Table created. SQL> alter table tbs allocate extent(size 200m); Table altered. SQL> select extent_id,block_id,blocks,file_id from dba_extents where segment_name=‘TBS‘ order by 1; EXTENT_ID BLOCK_ID BLOCKS FILE_ID ---------- ---------- ---------- ---------- 0 128 8 9 1 256 128 9 2 384 128 9 3 512 128 9 4 640 128 9 5 768 128 9 6 896 128 9 7 1024 128 9 8 1152 128 9 9 1280 128 9 10 1408 128 9 11 1536 128 9 12 1664 128 9 13 1792 128 9 14 1920 128 9 15 2048 128 9 16 2176 128 9 17 2304 128 9 18 2432 128 9 19 2560 128 9 20 2688 128 9 21 2816 128 9 22 2944 128 9 23 3072 128 9 24 3200 128 9 25 3328 128 9 26 3456 128 9 27 3584 128 9 28 3712 128 9 29 3840 128 9 30 3968 128 9 31 4096 128 9 32 4224 128 9 33 4352 128 9 34 4480 128 9 35 4608 128 9 36 4736 128 9 37 4864 128 9 38 4992 128 9 39 5120 128 9 40 5248 128 9 41 5376 128 9 42 5504 128 9 43 5632 128 9 44 5760 128 9 45 5888 128 9 46 6016 128 9 47 6144 128 9 48 6272 128 9 49 6400 128 9 50 6528 128 9 51 6656 128 9 52 6784 128 9 53 6912 128 9 54 7040 128 9 55 7168 128 9 56 7296 128 9 57 7424 1024 9 58 8448 1024 9 59 9472 1024 9 60 10496 1024 9 61 11520 1024 9 62 12544 1024 9 63 13568 1024 9 64 14592 1024 9 65 15616 1024 9 66 16640 1024 9 67 17664 1024 9 68 18688 1024 9 69 19712 1024 9 70 20736 1024 9 71 21760 1024 9 72 22784 1024 9 73 23808 1024 9 74 24832 1024 9 75 rows selected.
dump256和21760號塊，發現第一個塊的L1是管理64個塊第二個是有256個塊。經測試8M區大小的分區第8個分區以後L1中數據塊的數量就會達到256個塊。因此只要建立8m區大小的表空間插入一些數據將高水位擡到第8個分區以後就可以了。
buffer busy wait一例