在很多時(shí)候，我們都是需要保持業(yè)務(wù)的可持續(xù)性，盡管說DDL的過程持續(xù)時(shí)間很短，但是在線業(yè)務(wù)出現(xiàn)，就會阻塞DML，導(dǎo)致業(yè)務(wù)訪問中斷，事務(wù)收到影響，所以在有些場景下，高可用的需求可能比性能的需求優(yōu)先級還要高一些。
??? 比如一個(gè)分區(qū)表，突然發(fā)現(xiàn)分區(qū)的規(guī)則存在一些問題，如果需要重新規(guī)劃分區(qū)，部署，可能對于在線業(yè)務(wù)影響較大，能不能平滑的過渡到重新規(guī)劃的分區(qū)模式下。
??? 比如一個(gè)普通表，隨著數(shù)據(jù)量的增加發(fā)現(xiàn)已經(jīng)存在一些管理瓶頸，比如歷史數(shù)據(jù)的清理比較麻煩，想改為分區(qū)表的方式
??? 比如一個(gè)表需要添加若干字段，數(shù)據(jù)類型也需要調(diào)整等等，這類變更如果通過DDL完成對于在線業(yè)務(wù)的影響范圍較大
??? 比如一個(gè)表所在的分區(qū)空間不足，希望能夠在業(yè)務(wù)低峰期進(jìn)行數(shù)據(jù)的重構(gòu)。
有了在線重定義，這些看似困難的工作就會存在可能性，當(dāng)然萬事皆須付出代價(jià)，那就是在線重定義本身會消耗系統(tǒng)資源，這個(gè)需要合理評估，找到一個(gè)合適的時(shí)間點(diǎn)來完成。畢竟為了完成高可用的需求而帶來了嚴(yán)重的性能問題，那就得不償失了。
??? 有些場景還是不大適合在線重定義的，比如一個(gè)數(shù)據(jù)庫的表大小為50G,空間剩余不足10G,我們?nèi)绻褂迷诰€重定義的方案，那么就會存在很大的隱患。因?yàn)樵诰€重定義本質(zhì)上還是需要做一次底層的數(shù)據(jù)復(fù)制。這個(gè)就需要消耗系統(tǒng)資源，磁盤空間。
??? 在線重定義的一個(gè)亮點(diǎn)就是保持?jǐn)?shù)據(jù)的可持續(xù)訪問，基本原理是通過物化視圖的prebuilt方式完成，所以這種方案本身就是高可用，物化視圖的過程中對外是始終保持可訪問的連續(xù)性狀態(tài)，那么對于權(quán)限的控制則是這個(gè)之外的，所以我格外關(guān)心這部分的內(nèi)容。如果我們的環(huán)境存在下面這樣的情況，到底在線重定義的過程中是否會很穩(wěn)定呢，我們可以做對比測試來驗(yàn)證。
如果存在大量的連接用戶，在線重定義是否依然能夠保證業(yè)務(wù)的可持續(xù)進(jìn)行。

盡管我們知道從技術(shù)原理上是可以支持的，但是如果進(jìn)一步驗(yàn)證測試，我想就需要更全面的測試環(huán)境了。
我們分為三個(gè)場景來測試。
第一個(gè)是通過shell不斷生成會話去使用SQL調(diào)用基表的數(shù)據(jù)，看看是否會有中斷。
第二個(gè)是通過一個(gè)已經(jīng)存在的會話窗口不斷的通過SQL去調(diào)用基表的數(shù)據(jù)，查看是否中斷
第三個(gè)是通過大量的DML操作，查看在線重定義的過程中，是否依然能夠穩(wěn)定運(yùn)行。

我們初始化了一下的數(shù)據(jù)。
我們創(chuàng)建基表用戶ref_owner,連接用戶ref_conn
創(chuàng)建基表test_online_ref
## init
set echo on
create user ref_owner identified by oracle;
create user ref_conn identified by oracle;
grant connect,resource to ref_owner;
grant connect to ref_conn;
grant create synonym to ref_conn;

##owner account: ref_owner
conn ref_owner/oracle

CREATE TABLE test_online_ref
?? ( ?
?? col1 varchar2(30), ?
?? col2 DATE ?
?? )? ;
alter table??? test_online_ref modify(col1 primary key);
生成近300萬數(shù)據(jù)
insert into test_online_ref select level,sysdate+level*0.01 from dual connect by level<3000000;
commit;
grant select,delete,insert,update on ref_owner.test_online_ref to? ref_conn;
然后在連接用戶創(chuàng)建同義詞。
##connect account: ref_conn
conn ref_conn/oracle
create synonym ref_conn.test_online_ref for ref_owner.test_online_ref;
select count(*)from ref_conn.test_online_ref;
然后創(chuàng)建變更后的表。表結(jié)構(gòu)信息可以根據(jù)需求來定義改變，比如從改一個(gè)普通表變?yōu)榉謪^(qū)表。
conn ref_owner/oracle
CREATE TABLE new_ref ?
?? ( ?
?? col1 varchar2(30), ?
?? col2 DATE ?
?? ) ?
?? partition BY range(col2) ?
?? ( ?
?? partition tab_part_1 VALUES less than (to_date('2016-10-01','yyyy-mm-dd')), ?
?? partition tab_part_2 VALUES less than (to_date('2017-10-01','yyyy-mm-dd')), ?
?? partition tab_part_3 VALUES less than (to_date('2018-10-01','yyyy-mm-dd')),
?? partition tab_part_4 VALUES less than (to_date('2019-10-01','yyyy-mm-dd')),
?? partition tab_part_maxvalue values less than (maxvalue)
?? ); ?

grant select,delete? on ref_owner.new_ref??? to ref_conn;

數(shù)據(jù)初始化完成，接下來我們需要做的是在線重定義了。
其實(shí)腳本就是下面的幾行內(nèi)容。
exec dbms_redefinition.can_redef_table('REF_OWNER','test_online_ref',1); ?
exec? DBMS_REDEFINITION.CAN_REDEF_TABLE('REF_OWNER','test_online_ref',2); ?
exec? DBMS_REDEFINITION.START_REDEF_TABLE('REF_OWNER','test_online_ref','new_ref',NULL,2); ?
exec? DBMS_REDEFINITION.FINISH_REDEF_TABLE('REF_OWNER','test_online_ref','new_ref');

在線重定義的過程中，我們會并發(fā)調(diào)用開始所說的3個(gè)腳本來調(diào)用。然后觀察是否會存在ORA的錯(cuò)誤。
第一個(gè)場景的腳本如下：
function test_conn
{
sqlplus -s ref_conn/oracle <<EOF
set feedback off
set time on
col systimestamp format a35
select systimestamp,count(*)from test_online_ref;
EOF
}

for i in {1..1000000}
do
test_conn
done

剩下兩個(gè)場景的腳本，套路都是類似的，通過頻繁的DML或者查詢來完成
比如查詢
select systimestamp,count(*)from test_online_ref;
比如DML
delete from test_online_ref where rownum<2;
commit;

很快就測試完畢，查看日志沒有任何的ORA錯(cuò)誤。所以我們可以得到一個(gè)肯定的測試結(jié)果就是在線重定義是可信賴的。
得到的日志類似下面的形式：
我們可以從日志看到數(shù)據(jù)在極短的時(shí)間內(nèi)發(fā)生變化依舊可以保持?jǐn)?shù)據(jù)的可持續(xù)訪問變更。盡管會出現(xiàn)一定的卡頓，從日志里看大概是3秒鐘，但是業(yè)務(wù)訪問不會中斷。
SYSTIMESTAMP????????????????????????? COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.53.769959 PM +08:00??? 2923035

SYSTIMESTAMP????????????????????????? COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.53.898239 PM +08:00??? 2922896

SYSTIMESTAMP????????????????????????? COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.56.325261 PM +08:00??? 2922722

SYSTIMESTAMP????????????????????????? COUNT(*)
----------------------------------- ----------
18-SEP-16 10.49.56.454042 PM +08:00??? 2922599

變更完成后，原來的分區(qū)表new_ref就變成了普通表。
SQL> select dbms_metadata.get_ddl('TABLE','NEW_REF','REF_OWNER') from dual;?????
? CREATE TABLE "REF_OWNER"."NEW_REF"
?? (??? "COL1" VARCHAR2(30),
??????? "COL2" DATE,
???????? PRIMARY KEY ("COL1")
。。。。
大家有問題可以補(bǔ)充，有些場景下還是值得提倡的。

總結(jié)

以上是生活随笔為你收集整理的在线重定义的补充测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。