線上重定義的補充測試(r10筆記第26天)
在很多時候，我們都是需要保持業務的可持續性，儘管說DDL的過程持續時間很短，但是線上業務出現，就會阻塞DML，導致業務訪問中斷，事務收到影響，所以在有些場景下，高可用的需求可能比效能的需求優先順序還要高一些。 比如一個分割槽表，突然發現分割槽的規則存在一些問題，如果需要重新規劃分割槽，部署，可能對於線上業務影響較大，能不能平滑的過渡到重新規劃的分割槽模式下。 比如一個普通表，隨著資料量的增加發現已經存在一些管理瓶頸，比如歷史資料的清理比較麻煩，想改為分割槽表的方式 比如一個表需要新增若干欄位，資料型別也需要調整等等，這類變更如果通過DDL完成對於線上業務的影響範圍較大 比如一個表所在的分割槽空間不足，希望能夠在業務低峰期進行資料的重構。 有了線上重定義，這些看似困難的工作就會存在可能性，當然萬事皆須付出代價，那就是線上重定義本身會消耗系統資源，這個需要合理評估，找到一個合適的時間點來完成。畢竟為了完成高可用的需求而帶來了嚴重的效能問題，那就得不償失了。 有些場景還是不大適合線上重定義的，比如一個數據庫的表大小為50G,空間剩餘不足10G,我們如果使用線上重定義的方案，那麼就會存在很大的隱患。因為線上重定義本質上還是需要做一次底層的資料複製。這個就需要消耗系統資源，磁碟空間。 線上重定義的一個亮點就是保持資料的可持續訪問，基本原理是通過物化檢視的prebuilt方式完成，所以這種方案本身就是高可用，物化檢視的過程中對外 是始終保持可訪問的連續性狀態，那麼對於許可權的控制則是這個之外的，所以我格外關心這部分的內容。如果我們的環境存在下面這樣的情況，到底線上重定義的過程中是否會很穩定呢，我們可以做對比測試來驗證。 如果存在大量的連線使用者，線上重定義是否依然能夠保證業務的可持續進行。
儘管我們知道從技術原理上是可以支援的，但是如果進一步驗證測試，我想就需要更全面的測試環境了。
我們分為三個場景來測試。
第一個是通過shell不斷生成會話去使用SQL呼叫基表的資料，看看是否會有中斷。
第二個是通過一個已經存在的會話視窗不斷的通過SQL去呼叫基表的資料，檢視是否中斷
第三個是通過大量的DML操作，檢視線上重定義的過程中，是否依然能夠穩定執行。
我們初始化了一下的資料。
我們建立基表使用者ref_owner,連線使用者ref_conn
建立基表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);
##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;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;
其實指令碼就是下面的幾行內容。
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');
線上重定義的過程中，我們會併發呼叫開始所說的3個指令碼來呼叫。然後觀察是否會存在ORA的錯誤。
第一個場景的指令碼如下：
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
剩下兩個場景的指令碼，套路都是類似的，通過頻繁的DML或者查詢來完成
比如查詢
select systimestamp,count(*)from test_online_ref;
比如DML
delete from test_online_ref where rownum<2;
commit;
很快就測試完畢，檢視日誌沒有任何的ORA錯誤。所以我們可以得到一個肯定的測試結果就是線上重定義是可信賴的。
得到的日誌類似下面的形式：
我們可以從日誌看到資料在極短的時間內發生變化依舊可以保持資料的可持續訪問變更。儘管會出現一定的卡頓，從日誌裡看大概是3秒鐘，但是業務訪問不會中斷。
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
變更完成後，原來的分割槽表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")
。。。。
大家有問題可以補充，有些場景下還是值得提倡的。