**：
一次小資料量刪除，但花費2個小時還沒完成的問題
delete from topbox_courseware where id like '760%';
花費非常長的時間，topbox_courseware表大概2w資料，要刪除的也就2500條資料。
問題原因：
由於topbox_courseware表與多個表有外來鍵關聯，而且關聯的表中有2張千萬級別的大表。
通過v$session_wait,v$session表
select * from v$session_wait a,v$session b
where b.sid=a.sid
and a.event not like 'sql*net%';
發現該session的event是db file scattered read。
這個事件一般是表示法傷了全表掃瞄相關的等待。通常意味著全表掃瞄過多，或者i/o能力不足，或是i/o爭用造成的。
解決方法：
1.通過dba_constraints表找到topbox_courseware表對應的約束
select * from dba_constraints where constraint_type='r' and wner='topbox' and r_constraint_name='pk_topbox_courseware'
得到兩個外來鍵約束名
fk_topbox_coursco_ref_cour
fk_topbox_cstudy_ref_couse
2.通過命令將這2個約束disable
alter table topbox_coursescore disable constraint fk_topbox_coursco_ref_cour;
alter table topbox_coursestudy disable constraint fk_topbox_cstudy_ref_couse;
通過上面的處理delete只需要不到1秒的時間
3.將約束重新啟用
由於topbox_coursescore，topbox_coursestudy是千萬級的大表，如果直接enable而不加其他引數，啟用約束後，
oracle會對錶中資料
逐條檢查，所以速度會非常慢。而且已經插入的資料沒有髒資料，所以為了避免不必要的工作，就要使用novalidate
alter table topbox_coursescore enable novalidate constraint fk_topbox_coursco_ref_cour;
alter table topbox_coursestudy enable novalidate constraint fk_topbox_cstudy_ref_couse;
記一次database cpu high的處理
基本上，我們的資料庫例項每次cpu飆公升都是因read而起，很少有write導致的cpu高。這說明read，隨機讀，排序，都會占用cpu。而寫入主要是io行為，尤其是順序寫，不需要佔cpu。今次問題，rds在三個小時內都很高，始終維持50 最高甚至到98 當然我們的業務可用性並不依賴rds。觀察一段...
記一次tp喚醒函式異常導致的lcd喚醒慢
機器休眠後,按電源鍵喚醒,2s多螢幕才亮，檢視核心資訊，沒發現什麼報錯資訊。先檢查lcd的初始化 去掉多餘的延時，喚醒時間依然很長。繼續分析核心資訊，從按下電源鍵到開背光，用時2s多，發現tp喚醒時間較長。直接修改tp的i2c位址 或者拔掉tp 讓tp驅動不跑，喚醒時間就正常了。繼續分析tp的喚醒函...
一次SQL慢查詢記錄
前段時間，某個深夜，突然接到專案的告警 專案執行異常，檢視告警資訊是由於專案資料庫cpu使用率接近100 導致的。為此深夜中忙活了一陣，當個教訓，且記錄一次。現象 服務資料庫cpu使用率接近100 一直居高不下。原因 sql語句使用不合理的索引，導致資料庫中大量資料的排序，大資料量的記錄排序消耗盡c...