【系統環境】：
系統環境：sun solaris10 u11 + oracle 11.2.0.4.0 rac
【背景描述】：
從2023年11月起，生產的資料庫期的出現了兩次m0001程序120秒無法啟動：
主要報錯：waiting for 0x3800fe418 child shared pool level=7 child#=2，引起資料庫異常的故障。專家分析得出的結論：統計收集作業觸發shared pool空間需求，並出現收縮與擴容操作，先收縮說明shared pool空間容量不足或碎片嚴重導致無法找到可以使用的記憶體。當shared pool空間不足和存在碎片時會觸發空間收縮與擴容。
【監控前情況】
統計收集作業觸發shared pool空間需求，並出現收縮與擴容操作，先收縮說明shared pool空間容量不足或碎片嚴重導致無法找到可以使用的記憶體。當shared pool空間不足和存在碎片時會觸發空間收縮與擴容。則需要對sharedpool使用情況進行監控。
對於表設計想法：
1，由於該資料庫的sharedpool使用情況檢視方法很多種，怎樣更直觀體現sharedpool的使用情況，確認用百分比及總空間和剩餘空間進行監控sharedpool；
2，存放資料應該存放監控資料的表空間audit_data不影響應用使用的表空間,考慮到該資料庫儲存不足不能擴容，更容易分析時間段的資料，基於該條件情況下對錶進行生命週期管理，則應該建立月分割槽表check_sharedpool。
建立監控check_sharedpool分割槽表：
create table xj_exp_data. check_sharedpool
(inst_id number,
"free_shared_pool(mb)" number,
"total_shared_pool(mb)" number,
freepct varchar2(10),
sample_time date dedault sysdate)
partition by range (sample_time)(
partition p201701 values less than (timestamp '2017-01 00:00:00') ,
partition p201702 values less than (timestamp '2017-02 00:00:00') ,
..........----省略其他分割槽語句
partition pmax values less than (maxvalue) )
tablespace audit_data;
對於部署想法：
1，考慮到sharedpool的使用情況，資料庫的每個節點都不一樣，則需要每個節點都需要部署任務進行監控sharedpool；
2，考慮到對資料庫sharedpool監控資料需要測試監控的可行性，則在對應生產的測試庫進行測試監控三天檢視監控情況；
3，考慮到資料的監控需求性，記錄監控資料是否準確，定製採集資料頻率為一小時；
在測試庫測試該監控情況正常後，則謄寫方案，內部審核後，提單對生產庫進行部署sharedpool監控指令碼及定時任務。
【監控優化】
對其生產監控sharedpool最後生成資料效果如下：
中間監控優化步驟如下：
1，sql的優化：考慮到需要同時對比兩個節點的sharedpool使用情況。則需要sql查詢組合多個節點資料;
2，採集資料優化：對於生產庫比較多，需求每天提供監控sharedpool使用情況資料，有時突然需求sharedpool的使用情況，則考慮用監控主機使用pyahon進行採集資料;
3，圖形優化：考慮更加直觀檢視sharedpool的使用情況趨勢，想到南基採資料庫週報資料也是用python,則用python直接生成圖形監控資料;
vi sharedpool.py
# -*- coding:utf-8 -*-
import xlsxwriter, cx_oracle, sys
reload(sys)
sys.setdefaultencoding('utf-8')
database_list =
for d in database_list:
print(d)
conn = cx_oracle.connect(database_list[d])
# connect_database
c = conn.cursor() #get cursor
x = c.execute('''
select s.snap_time,s.inst_id1,s.inst_id2,d.name,s.total_mb_inst1,s.free_mb_inst1,
s.total_mb_inst2,s.free_mb_inst2
from (select a.snap_time,a.pct inst_id1,b.ptc inst_id2,a.total_mb total_mb_inst1,a.free_mb free_mb_inst1,b.total_mb total_mb_inst2,b.free_mb free_mb_inst2 from
(select to_char(trunc(sample_time +10/60/24, 'hh24'),'yyyymmdd_hh24') snap_time,inst_id,"free_shared_pool(mb)" free_mb,"total_shared_pool(mb)" total_mb,to_number(replace(freepct, '%', '')) pct
from xj_exp_data.check_sharedpool partition (p201703) where inst_id = 1) a
left join ..............-------新增多個節點內容
left join (select to_char(trunc(sample_time +10/60/24, 'hh24'),'yyyymmdd_hh24') snap_time,inst_id, "free_shared_pool(mb)" free_mb,"total_shared_pool(mb)" total_mb,to_number(replace(freepct, '%', '')) pct
from xj_exp_data.check_sharedpool partition (p201703) where inst_id = 2) b
on a.snap_time = b.snap_time(+)order by to_date(a.snap_time, 'yyyymmdd hh24')) s,
(select name from v$database) d ------用以識別多個資料庫
''')
dbname = x.fetchone()[3]
row = x.fetchall()
..........--------省略部分內容
# add a chart title and some axis labels.
chart1.set_title()
# set an excel chart style. colors with white outline and shadow.
chart1.set_style(10)
# insert the chart into the worksheet (with an offset).
worksheet.insert_chart('g2', chart1, )
c.close()
conn.close()
workbook.close()
【總結】：
1，監控資料庫的專案時，同時考慮是否多個節點資料一樣。
2，對於多個資料庫監控，python有非常大的幫助。
在linux中對vbox的cpu使用率監控
目前，每天中午cpu的負載都會突然增加，通過htop命令檢視到此時的vbox的cpu佔用率一致蠻高的，便計畫對vbox的cpu使用率進行計畫性監控，最開始的想法很簡單就是通過呼叫top命令來進行cpu使用率的監控，但監控了好幾天，發現值一直為0，而htop中值是一直有變化的，正常的結果也不應該為0，...
索引使用率
索引使用率 select distinct db name database id as n 資料庫名稱 object name a.object id as n 表名 b.name n 索引名稱 user seeks n 使用者索引查詢次數 user scans n 使用者索引掃瞄次數 last ...
使用率 如何提公升B端產品的使用率
每個產品經理的需求池中，至少有90 的需求是市面上已經有現成的方案了，所以站在功能實現的角度，產品經理是不需要重複造輪子的。以至於對於所有產品經理來說，出需求都在焦慮一件事情，實現的產品到底有沒有人用？首先 有沒有人用 要如何量化呢？對於c端產品而言最基本的指標就是dau和mau，而b端產品更多指的...