在試驗中嘗試了2種更新資料的方法：
1.update table set ... where ...
2. 先根據更新條件建立臨時表，再刪掉未更新之前的表，最後把臨時表更名為原始表名
通過試驗很明顯的可以認識到update的效率是非常之低的。通過在網上跟其他oracle使用者的討論，也都一致的認為，大資料量更新應該採用第二種方法
被更新的表名：test_mt_sms
資料量：1500w左右(具體數字搞忘了)
待更新的資料量：7151773
採用第一種方法：
更新語句：
update test.test_mt_sms t1 set channel_code='$channel_code',sub_channel_code='$sub_channel_code' where #service_id='$service_id' and recv_address='$user_name'
這個sql從22:24跑到第二天上班都還沒完。。。幾乎是乙個不可完成的任務了。
採用第二種方法：
建立臨時表的sql語句：
create table test. tmp_mt_sms
tablespace tbs_sub
asselect
t1.misc_msg_id,
t1.msg_id,
t1.msg_type,
t1.fee_type,
t1.fee_value,
t1.send_address,
t1.recv_address,
t1.fee_address,
t1.down_station,
t1.outter_id,
t1.service_id,
t1.oss_recv_code,
t1.mt_type,
t1.mt_content,
t1.mt_time,
t1.carry_msg,
t1.carry_id,
decode(t3.link_id,null,t2.channel_code,'web') channel_code,
t2.sub_channel_code,
t2.reg_mode,
t2.unreg_mode,
t2.enable_status,
t2.first_reg_time,
t2.last_reg_time,
t2.last_unreg_time,
t1.rpt_flag,
t1.rpt_state,
t1.gateway_rpt_state,
t1.link_id,
t1.err_detail
from test.tmp_oicall_info_20070206 t1
left join test.tmp_sso_mt
t3on t3.stat_date=to_date('2007-02-06', 'yyyy-mm-dd')
and t3.link_id = t1.link_id
left join
test.tmp_user_info t2
on t2.user_num = t1.recv_address
and t1.service_id = t2.service_id
/# elapsed: 00:13:05.74//
再加上drop table 和rename table ，總耗時穩定在20分鐘之內
通過這個試驗，很明顯的深刻的認識到了update的低效，所以對大資料量更新一定要慎重的使用update
oracle中大資料量join操作的試驗
通過關聯訂購關係這個操作做了乙個關於join操作的試驗。以前採用上下行表直接關聯，2個表資料量大約是2200w左右和1400w左右，並且2個表都是屬於寬表，字段內容多，占用空間大，但join的時候用到的字段很少 2個左右 因此很多記憶體都耗在了儲存不必要的字段值。每次關聯操作耗時在2個小時以上。通過...
Oracle大資料量遷移
prompt 生成歷史表，使用nologging create table his test nologging as select from test prompt 檢驗新舊表的資料量是否一致 select count 1 from test select count 1 from his tes...
ORACLE 大資料量更新表不寫日誌
2.假如tab1表中的沒有資料的話 drop table tab1 create table tab1 as select from tab2 然後在建立索引 3.用hint 提示減少操作時間 4.採用不寫日誌及使用hint提示減少資料操作的時間。建議方案是先修改表為不寫日誌 sql alter t...