【oracle】高併發量表更新注意點

一個業務高併發，接入一個客戶電話就發一個特殊邀請碼（碼爲字符加數字混編，無規律），碼已存表，業務上要 邀請碼和用戶手機號碼一一對應；
因此，來個用戶就得對未標記的碼更新手機號碼；高併發時，行鎖及等待比較耗時，致使數據庫性能降低嚴重；更新的操做都在存儲過程當中。

因此，不改動程序在數據庫層解決此問題的辦法就是：

解決辦法，
碼錶增長seqid,字段；導入數據時使用rownum,作該字段值,建索引；
更新時，使用序列，

 

CREATE SEQUENCE SQ_U_SEQ INCREMENT BY 1 START WITH 1 MAXVALUE 50000000 CYCLE CACHE 2000 NOORDER;
更新則：update ... where ... and t.seqid = SQ_U_SEQ.nextval ...;
之後有新的數據要導入，則序列需重置，則：

create or replace procedure seq_reset(v_seqname varchar2) as n number(10);
tsql varchar2(100);
 begin
 execute immediate 'select '||v_seqname||'.nextval from dual' into n;
  n:=-(n-1);
  tsql:='alter sequence '||v_seqname||' increment by '|| n;
  execute immediate tsql;
 execute immediate 'select '||v_seqname||'.nextval from dual' into n;
  tsql:='alter sequence '||v_seqname||' increment by 1';
 execute immediate tsql;
 end seq_reset;

另外，高併發時序列的cache要設置大點,通常業務設置100以上，但nocache的時候性能確實不好，最大相差20倍． 排序參數：oracle默認是NOORDER，若是設置爲ORDER；在單實例環境沒有影響，在RAC環境此時，多實例實際緩存相同的序列，此時在多個實例併發取該序列的時候，會有短暫的資源競爭來在多實例之間進行同步。因次性能相比noorder要差，因此RAC環境非必須的狀況下不要使用ORDER，尤爲要避免NOCACHE ORDER組合；