這個案例說來也很簡單。話說我們公司舊版本的
mediation
系統每天都需要從各個
network element（ne
）的伺服器上採集
cdr，採集程式一般都是用
expect
寫的，其實就是
ftp到對方的機器上拷貝檔案過來。
ne裡的
cdr一般不會輕易做
house keep
ftp登入之後，首先會使用
ls看上去天衣無縫吧。誰知道某一天，問題來了。大家知道，
ftp是有超時設定的，而採集程式
ftpftp
[25.05 10:34:05] step 001 log sql> ftp> bin
[25.05 10:34:05] step 001 log not connected.
[25.05 10:34:05] step 001 info ftp_client mo_bg-cdr_2010-05-25t000932.log.gz start copying
[25.05 10:34:05] step 001 log get cdr_2010-05-25t000932.log.gz /usr/users/nmds/amd/arm/input/raw/mo_bg1/tmp-mo_bg-cdr_2010-05-25t000932.log.gz-tmp
[25.05 10:34:05] step 001 log not connected.
還好日誌上有時間戳，記錄了採集程式從登入成功到真正開始傳輸，足足等待了超過
5分鐘，說明當中的查詢比較過程太慢了。翻看源程式，發現執行的
sql是：
select sysid from smt_ftp_files where sysid ='$sysid' and filename = '$filename';
不必多說，這個查詢應該在
filename
或者sysid
欄位上有索引，才會快。進入
oracle
2sql> select index_name from all_indexes where table_name='smt_ftp_files';
no rows selected
sql> create index idx_filename on smt_ftp_files(filename);
index created.
sql> select index_name from all_indexes where table_name='smt_ftp_files';
index_name
------------------------------
idx_filename
乙個sql引起的丟錶問題
背景 乙個已經執行了一段時間的老系統線上存在這種業務邏輯 start transaction drop tables if.a backup drop tables if.a tmp create table a tmp like a load into a tmp rename table a a...
乙個索引引發的問題
215 上了乙個大表的組合索引，引發了查詢sql的執行計畫混亂，最終cpu充到100 業務系統掛掉，庫也幾乎宕掉。1，為什麼建了索引後，oracle執行計畫會亂掉，而且選擇了乙個最慢的執行計畫?dba答覆 表關聯！關聯表越多，oracle選擇執行計畫出錯的概率變大！如何防止此類事件 上索引之前，先固...
乙個指標引起的問題，尋求高人指點
自己寫的一段測試 如下 include include int getxmltagvalue2 char pdata,char ptag,char value phead j ptail phead while ptail while phead ptail printf d n j return ...