背景：
2月份的一天電信系統突然夯死，業務應用緩慢無比，經過分析發現一張大表（業務明細表
order_detail_l
）的執行計畫變更了，本來應該走索引的，結果變更為全表掃瞄，該錶有
5億條記錄，全表掃瞄絕對是個噩夢。
分析原因發現統計資訊採集率不夠，資料庫的自動採集功能已經開啟，但是預設的採集率是
5%，貌似對於這樣的大表來說遠遠不夠，重新按照
100%
採集後執行計畫恢復正常，
語句如下：
exec
dbms_stats.gather_table_stats(ownname=>
'liomuser'
,tabname=>
'order_detail_l'
,degree
=>
6,estimate_percent=>
100); 注：
dbms_stats.gather_table_stats
進行統計資訊採集時，
cascade
預設為yes
，即對錶分析的同時，索引等其他關聯物件也進行了分析，
estimate_percent
引數為採集率。
對於由於採集率過低導致的執行計畫便跟問題，
oracle
官方給出的解釋是
bug
但是效率任然很低，因為資料量多索引過大，及時走索引，效率仍然不高，最後決定將生產庫資料挪到歷史查詢庫，生產保留
6個月資料。
生產庫需要遷移將近
4年的資料，
85張表共
320g
，最大的表有
6億記錄，大小為
40g，其中大小查過
20g的表有
20張。
局方要求不能影響生產環境，
mygod
！這絕對是個折磨人的活，局方要求所有執行指令碼包括業務邏輯判斷都精確到分鐘。
遷移環境：
hp-ux b.11.23 u 9000/800
oracle database 10g enterprise edition release 10.2.0.4.0 - 64bi
遷移步驟： 1、
編寫邏輯處理包
pkg_dump_util
，主要功能是：
（1）處理判斷各表的歸檔臨界點。
（2）切割歸檔
dump
檔案，（由於系統對
dump
問題有大小的限制，需要通過表分組實現來將資料割接開來）
（3）自動生產匯出語句
（4）邏輯判斷，匯出資料是否業務完整性 2、
採用自動生成的語句匯出表資料，（採用資料庫幫浦
expdp）
匯出技術點滴：
（1）只匯出資料
content=data_only
（2）指定每個
dump
包含的表，
tables=(t_name1,t_name2,t_name3)
匯出時間統計：
（1）共320g
資料，共耗時
6個小時，最大
dump
檔案是48g
（2）最大表匯出耗時
2個小時，共
37g
3、 歷史查詢庫資料匯入，該環節是最麻煩的環節，最大的歷史表
serv_field_change_l共14
億資料，無論是資料匯入還是索引維護都是乙個漫長的過程，按照要求還不能影響生產。
我決定冒險一試，與局方討價還價的結果就是，我按照預定時間做操作，但是不能保證在預定時間完成，如果出現超時的情況，需要停止全省的歷史查詢功能，確保操作順利完成，最後局方妥協。
匯入技術點滴：
(1)
impdp
在匯入時會自動維護統計資訊和索引，但是其維護索引的速度比單獨建立索引效率低，故後面很多表都是先置索引失效然後再重建索引:
操作語句：
指當表存在時，資料庫幫浦只是附加資料
另外幾個需要注意的引數：
remap_schema
：當需要將乙個
schema
的資料匯入到另乙個
schema時，
需要只出原
schema
和新的schema
，不過貌似
impdp不
能在表名不同的表間導資料。
parallel
：原本想增加這個引數，開並行提高速度，但是加上後語句報「
dump
檔案無法找到」，狂暈
索引置失效語句：
alter index liomuser.idx_serv_field_change_lis unusable;
索引重建語句：
alter index liomuser.idx_serv_field_change_lis rebuild;
主鍵置失效語句：
alter table liomuser.serv_field_change_l
disable constraint pk_product_relation_i_p_lnj2;
主鍵恢復語句：
alter table liomuser.serv_field_change_l enable constraint pk_serv_field_change_lis;
(2)歷史庫查詢庫和生產庫出現表結構不一致的情況，這個問題需要重視，已經給公司發了郵件。
(3)歷史查詢庫和當前生產庫的索引不一致情況，（歷史庫索引少），我的分析認為缺少的索引在歷史查詢中沒有用到，索引不需要和生產一致。
(4)匯入時間記錄：
以最大的表為例，
serv_field_change_l，
資料匯入：
2個小時
索引重建：
4個小時
主鍵恢復：
6個小時（該錶主鍵有
5個字段，瘋掉了！）
資料大小：
37g
歷史表總資料量：
14億條（每個中國人一條記錄，還有多的，暈！）
關於匯入環節的一點總結：1
、預留足夠多的時間，本次遷移時間非常緊張，出現了一些意料外的問題，另外
完成操作後一定要測試效能。 2
、實踐證明，將索引置失效再匯入資料，然後再重建索引，比利用資料庫幫浦維護
索引要快很多。 3、
在生產環境進行操作前，一定要比對錶結構和索引，對於差異的要補充，對於索引的差異，一定要考慮到遷移後資料量的變化對執行計畫的影響，完善和分析索引以及壓力測試是很必要的。 4、
生產庫清理，將已經歸檔的資料重生產環境清除：
實施策略：
（1）建立臨時表，原表名
_tmp
，將保留資料插入臨時表
（2）臨時表統計資訊採集
（3）將臨時表切換為生產表
注意事項：提取表的
ddl語句，建議最好使用
dbms_metadata
工具，因為在實際的操作中發現
plsql
提取的ddl
語句有不完整的地方
總結：遷移事關生產系統，一定要仔細規劃，提前固定好執行指令碼，做好測試工作，確保在執行中不用臨時修改，任何乙個引數的變動都會產生不可預期的後果。
規劃好時間，明確時間點和責任。
最後給出乙個比較有用的
sql，監控事務進度：
select username,
sid,
opname,
round(sofar * 100 / totalwork, 0) || '%' as progress,
time_remaining,
sql_text
from gv$session_longops, gv$sql
where time_remaining <> 0
and sql_address = address
and sql_hash_value = hash_value 其中
gv$session_longops
是oracle
的動態效能檢視，記錄執行超過
10s的事務執**況。
半年的工作心得與總結
眨眼間已經畢業半年,在這半年裡吃了好多苦,這些苦好多人也許都無法想像,現在覺得自己成熟了不少,為了適應,試圖著改掉了不少 毛病 但難以改變的還是自己的性格,不習慣那些場合中的阿諛逢迎和爾虞我詐,現在想想,也許我真的還沒有分清什麼是尊重，而什麼又是奉承。為了適應，在我認為是奉承的時候姑且想把它想象成是...
工作總結 基於R的資料分析
終於有那麼一丟丟時間，可以來把關於r語言程式設計的工作梳理一下。總體來說，工作內容主要是將公司已有的excel模板的資料分析內容轉為r語言形式，目前寫了四個產品的資料清洗和分析 在這中間，學習到了很多新知識。對接下來，程式設計之路的走向有了初步的規劃。對資料分析這塊也增加了認識吧。關於新知識 1 較...
GAN與NLP的結合相關資料彙總與總結
總結 目前嘗試的內容 純文字生成，詩歌生成，唐詩生成，機器翻譯，ir,中文分詞，文字分類 主要思路 考慮使用d進行真假判別，然後用rl的policy gradient的方式來打分和更新 使用word2vec之類的連續向量，微調之後不能代表乙個有意義的詞語，可以考慮取最近的點,但是存在bias，對於部...