f 九月 2019 ~ 迪貝之家

Microsoft SQL Server Log Shipping

SQL 7就有的技術,簡單的說就是資料庫複本資料同步的技術,而這份複本可以開放讀取的功能以分散營業資料庫的負載,也可純粹當成備援資料庫,不管是在本地還是異地。怎麼達成? 透過SQL Agent自動化排程進行備份、傳檔及復原等作業。

Oracle GolGateden

機房搬遷跨Site能即時同步資料庫利器

Nagios 資料庫維運自動化

一開始設計這架構時,就排除使用remote agent的想法因為在專業分工的組織下,要求安裝新軟體於既有系統是一件不太可行的方案,既然身為DBA就只能把資料庫instance當作是一個最大的agent 想辦法在資料庫內做到我想做的事情

This is default featured post 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured post 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Oracle 資料庫跨Site 同步資料

OGG for Oracle DB Upgrade

這個Case 真的是有夠累的!!
整個專案運作至少跑了半年
它把我們內部機房搬遷及資料庫升級專案整個攪在一起
上次升級是8i升級到10gR2
但那是在同一個機房內,而且當時是找Oracle ACS 來做的
所以我只需要支援export/import而已
這次我一個人統包了
算是對我一次的重大歷練吧!!
技術細節如下,如果你想參考的話:


對於Oracle impdp在Index的部分為何Parallel 都只能以1來運作的疑問,在後來的測試驗證出來了。有一次匯資料前先把Index都建了出來, parallel 依照原有的script是為24, 我temp 開到150GB都不夠用,難怪Oracle RD會做這麼保守的設計




PDB : AP User 砍session

程式碼跟Oracle 非最高權限怎麼砍session 所示一模一樣
只是權限的問題而已
我的做法如下:
1. sys登入cdb後,轉換session context
alter session set container=test;

2. 給出query v$session的權限
grant select on v_$session to system;

3.給出其他相關權限
grant create any directory to system;
grant alter system to system;

4. 以system登入PDB,建立public synonym
create public synonym kill_session for system.kill_session;

5.給予AP帳號執行kill_session程式的權限
grant execute on kill_session to your_ap_user;


Patching Steps For RAC 12.2 64bits on RedHat Linux 7.x 64bits

dbhaX, 其中X指的是各RAC NODE的代號
要打補丁,至少要對Oracle RAC架構有一定的了解吧!!
所以我就不多做解釋了
Patch的文件雖然沒甚麼大用
但還是要看一遍啦!!
我的patch放在底下路徑
/home/grid/patch/29708720

1. 以Oracle 登入,停掉DB Instance
$ORACLE_HOME/bin/srvctl stop home -o $ORACLE_HOME -s /home/oracle/patch.txt -n dbhaX

2. 切到root身份,執行GI_HOME底下的指令
$GRID_HOME/crs/install/rootcrs.sh -prepatch

3. 切到grid身份, 打Grid Infra 補丁
$GRID_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/29757449
$GRID_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/29770040
$GRID_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/29770090
$GRID_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/26839277
$GRID_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/28566910

4. 切到oracle 身份,打DB 補丁

/home/grid/patch/29708720/29770040/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/29770040
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /home/grid/patch/29708720/29757449

/home/grid/patch/29708720/29770040/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME

5. 以root 身份進到GRID_HOME執行下列兩個指令
$GRID_HOME/rdbms/install/rootadd_rdbms.sh
$GRID_HOME/crs/install/rootcrs.sh -postpatch

7. 以oracle身份,啟動db instance
$ORACLE_HOME/bin/srvctl start home -o $ORACLE_HOME -s /home/oracle/patch.txt -n dbhaX


8.上述七個步驟依序在各RAC Node打完補丁之後
  只需要以oracle身份在其中一個node 進行datapatch的動作
cd $ORACLE_HOME/OPatch
./datapatch -verbose


今天10/17,打了第四季的Patch,其實它固定都會出現一個可以忽略的錯誤(grid),不要被嚇到了,因為Oracle自己都在Log裡頭寫可以ignore...這個真的很好笑....阿就直接修正就好了...

Delete table with lob securefile causes fragmentation

系統持續在清檔,但表格使用空間卻不斷地成長
DBA能做的就是查找資料
透過google search 及查詢mtealink
至少看了六篇Oracle的技術文件
才有一個結論出來
底下是我跟AP Leader的互動
---------------------------------------------
    經研究下列文件,進行該表LOB物件所佔空間的分析
How to Determine what storage is used in a LOBSEGMENT and should it be shrunk / reorganized? (Doc ID 1453350.1)
    跑出來的數據如下:
SQL> exec check_space_securefile('ADM','LOB_STORE_BCK_1');
Segment Blocks/Bytes   = 21510808 / 176216539136
Unused Blocks/Bytes    = 39917 / 327000064
Used Blocks/Bytes      = 14816995 / 121380823040
Expired Blocks/Bytes   = 6653896 / 54508716032
Unexpired Blocks/Bytes = 0 / 0
===========================================================================
NON Data Blocks/Bytes  = 6693813 / 54835716096

PL/SQL procedure successfully completed.
文件指出該如何進行判斷物件是否有破碎空間
3) Determine if the LOBSEGMENT is a candidate for shrink / reorganization

The following query will show the extents allocated for the LOBSEGMENT

SELECT BYTES, COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_NAME = 'LOB_STORE_BCK_1' GROUP BY BYTES ORDER BY 2;

If NON Data Bytes is greater than one or more of the extent sizes from this query ...
     then this segment is a candiate for a shrink / reorganization as this process will likely be able to reduce the size of the LOBSEGMENT by at least one extent
query output :
     BYTES   COUNT(*)
---------- ----------
  47185920          1
    131072          1
     65536          1
  62914560          7
   1048576          8
  63963136         28
  67108864       2110
   8388608       3854

我的判斷是, fragmentaion大概浪費了約50GB的空間
那該表格整體空間到底佔了多少?
AP Leader說他們的語法抓出來是70幾GB
所以我用expdp estimate_only 來看囉~~
ESTIMATE_ONLY

坦白說, Oracle DBA如果沒有metalink
就等於老虎沒了牙

CREATE OR REPLACE PROCEDURE check_space_securefile (u_name in varchar2, v_segname varchar2 ) IS
     l_segment_size_blocks NUMBER;
     l_segment_size_bytes NUMBER;
     l_used_blocks NUMBER;
     l_used_bytes NUMBER;
     l_expired_blocks NUMBER;
     l_expired_bytes NUMBER;
     l_unexpired_blocks NUMBER;
     l_unexpired_bytes NUMBER;
     l_unused_blocks NUMBER;
     l_unused_bytes NUMBER;
     l_non_data_blocks NUMBER;
     l_non_data_bytes NUMBER;

     BEGIN
          DBMS_SPACE.SPACE_USAGE( segment_owner =>u_name,
                                  segment_name => v_segname,
                                  segment_type => 'LOB',
                                  segment_size_blocks => l_segment_size_blocks,
                                  segment_size_bytes => l_segment_size_bytes,
                                  used_blocks => l_used_blocks,
                                  used_bytes => l_used_bytes,
                                  expired_blocks => l_expired_blocks,
                                  expired_bytes => l_expired_bytes,
                                  unexpired_blocks => l_unexpired_blocks,
                                  unexpired_bytes => l_unexpired_bytes
           );

          l_unused_blocks := l_segment_size_blocks - (l_used_blocks + l_expired_blocks + l_unexpired_blocks);
          l_unused_bytes := l_segment_size_bytes - (l_used_bytes + l_expired_bytes + l_unexpired_bytes);

          l_non_data_blocks := l_unused_blocks + l_expired_blocks + l_unexpired_blocks;
          l_non_data_bytes :=  l_unused_bytes + l_expired_bytes + l_unexpired_bytes;

          DBMS_OUTPUT.ENABLE;
          DBMS_OUTPUT.PUT_LINE(' Segment Blocks/Bytes   = '||l_segment_size_blocks||' / '||l_segment_size_bytes);
          DBMS_OUTPUT.PUT_LINE(' Unused Blocks/Bytes    = '||l_unused_blocks||' / '||l_unused_bytes);
          DBMS_OUTPUT.PUT_LINE(' Used Blocks/Bytes      = '||l_used_blocks||' / '||l_used_bytes);
          DBMS_OUTPUT.PUT_LINE(' Expired Blocks/Bytes   = '||l_expired_blocks||' / '||l_expired_bytes);
          DBMS_OUTPUT.PUT_LINE(' Unexpired Blocks/Bytes = '||l_unexpired_blocks||' / '||l_unexpired_bytes);
          DBMS_OUTPUT.PUT_LINE('===========================================================================');
          DBMS_OUTPUT.PUT_LINE(' NON Data Blocks/Bytes  = '||l_non_data_blocks||' / '||l_non_data_bytes);
     END;

/
最後大家看了這數字
可以撐得住一年
就“按兵不動”囉!




SQL Server master 資料庫能否直接升級

最近有個案子,從2008 R2 企業版升級到2016 sp1 +cu6,因為partition功能支援的關係。
我是很懶得重建帳號及server link及proxy 帳號等相關設定,所以系統平移我都會透過備份master db,然後在新主機上倒回,上述的設定就不需要我手動config 了。不過這個方法在不同版本會無法進行,因問restore 指令會回覆你不相容,所以跨版本restore 只能用在user 資料庫。 
我不死心,就shutdown 08 R2 instance, 把系統資料庫拷貝到16 std對應的目錄,然後啟動instance。系統是開得起來的哦~啟動的過程中會進行catalog upgrade,就雷同上完更新的動做的。但會出錯的地方在於建立SSISDB,系統會告訴你key 不對,我不知道怎麼解,只好放棄。
結論就是,升級時就是中規中矩的安裝完之後,就是使用該版的系統資料庫,以免踩到雷。

ADG 可以透過AWR 報表查看效能了ㄝ

 初看原廠的官方文件時,坦白說,我真的看不懂

Managing Automatic Workload Repository in Active Data Guard Standby Databases

因為它的辭彙destination 及source 
與我們所認知相反
所以我去調了metalink的技術文件
最起碼它還給了我步驟
所以我的步驟就是根據2409808.1

基本原理就是
Primary 當成AWR STORE
透過建立對ADG的DBLINK
然後在Primary 告訴ADG
我要AWR 的資料
然後ADG主動收完資料後
傳回Primary
我覺得沒甚麼奧妙啦!!
Oracle 就說它是個架構
叫做RMF
(Remote Management Framework)
這個架構我覺得主要是在ADG執行
所以才需要ADG回Primary的DBLINK

以下建置步驟都是透過sys來進行
1.先啟動dblink要用到的帳號
  這是Oracle的設計
  只能透過它去抓取ADG遠端資料庫的效能資料

alter user sys$umf identified by test account unlock;

2.在Primary 建置雙向dblink
ADG node 會用到
因為資料會被redo transport 傳過去
不用特意到ADG NODE建立
唯讀模式下,我想你也建不出來
testcdb是primary
teststb是ADG
create database link testcdb_teststb CONNECT TO sys$umf IDENTIFIED BY test using 'teststb';
create database link teststb_testcdb CONNECT TO sys$umf IDENTIFIED BY test using 'testcdb';

3. RMF框架需要描述所有資料庫的關係
    我的理解它叫做Topology
    因此每個節點必須告知RMF
    它在Topolgy關係上的名稱
    我們就定義本機為prim
    沒給名稱,它就是找db_unique_name的值
    所以在Primary 上頭執行下列指令
exec dbms_umf.configure_node('prim');

4.在Standby
  這是唯一你要在ADG Node下的指令
  我也不知道
  為何read only 模式下
  還可以寫入資料 ??
  這就是奧妙囉~~
  當然定義ADG的名稱
  及它使用哪個DBLINK 傳回效能資料
exec dbms_umf.configure_node ('stby','teststb_testcdb');


5.On Primary
   建立我剛才所講關係的名稱

exec DBMS_UMF.create_topology ('Topology_1');

6.驗證Primary 是否建出 record

set line 132
col topology_name format a15
col node_name format a15
select * from dba_umf_topology;
select * from dba_umf_registration;














7.On Primary: 登錄ADG node
第五個參數, 比對文件2409808.1
及web 可查得到的官方文件
前者是false,後者是true
我去查了 dba_umf_registration.as_source的定義
我認為應該要給TRUE

exec DBMS_UMF.register_node ('Topology_1', 'stby', 'testcdb_teststb', 'teststb_testcdb','TRUE', 'FALSE');

8. 啟動ADG 資料庫 AWR Application:
exec DBMS_WORKLOAD_REPOSITORY.register_remote_database('stby');

9.建立ADG的AWR snapshot
  就跟原本AWR的運作一樣
  在Primary上
exec dbms_workload_repository.create_remote_snapshot('stby');
-- 只是我的環境
-- 一份snapshot的執行需要花費2分多鐘
-- 因為跑在不對稱的專線上

10.產出awr report
ADDM不用想了
因為沒辦法給DBID

?/rdbms/admin/awrrpti

11.秀一下ADG AWR 報表的標頭吧~~
AWR For ADG
























怎麼解除: 就逆向而行妹
Primary :
exec DBMS_WORKLOAD_REPOSITORY.unregister_remote_database('stby','Topology_1',TRUE);
exec DBMS_UMF.unregister_node ('Topology_1', 'stby');
exec DBMS_UMF.drop_topology ('Topology_1');
exec dbms_umf.unconfigure_node;

Standby:

exec dbms_umf.unconfigure_node;

Oracle revoke DBA的爛設計

有時為了方便AP作業
會暫時把DBA權限放出去
但收回時就出現space quota error
TMD,真是什麼爛設計啊!
人生就是在血和淚的教訓中成長
真的是很靠北

還真冤枉了前一次跟我要DBA權限的同仁,就發了line 給他,說聲抱歉。



Revoking DBA or RESOURCE Roles Revokes UNLIMITED TABLESPACE from the User (Doc ID 1084014.6)
Last updated on AUGUST 04, 2018

APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.1.7.0 to 11.2.0.3 [Release 8.1.7 to 11.2]
Information in this document applies to any platform.
Checked for relevance on 31-May-2013

SYMPTOMS
Revoking either RESOURCE or DBA roles revokes the UNLIMITED TABLESPACE privilege.

SQL> connect system/manager ---> this will be referred to as Session 1
Connected.

SQL> create user abc identified by abc;
Statement processed.

SQL> grant connect, resource to abc;
Statement processed.

SQL> connect abc/abc ---> this will be referred to as Session 2

SQL> create table test1 (c1 number);
Table created.

From another session connected as SYSTEM:

Session 1(SYSTEM):

SQL> grant dba to abc;
Statement processed.

SQL> revoke dba from abc;
Statement processed.

Session 2(ABC):

SQL> create table test2(c1 number);
create table test2(c1 number)
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace 'SYSTEM'


When the dba privilege is revoked, the quota resources from any tablespace are lost although they were acquired earlier via another role(RESOURCE).

Re granting the RESOURCE role to the user, will allow the user to allocate space in the tablespaces.

Session 1(SYSTEM):

SQL> grant resource to abc;
Statement processed.

Session 2(ABC):

SQL> create table test2(c1 number);
Table created.

差點被微軟的Log Shipping給搞死

三個禮拜前,在一個環境上建立Log Shipping
就奇怪了哩~~ 
怎麼追了幾個交易記錄檔後就掛了哩~~
當下百思不解
出了問題,當然會去看系統記錄
但是訊息太雜亂
真正有用的訊息就被淹沒掉了
幾百行裡頭就一行的錯誤代碼是真的有參考價值
是後來我找到原因
也實際再次implement後
真的解了
才去仔細對照log的, 如下
9004




Debug的邏輯如下
出錯是嗎?
那我就手動跑系統在排程內所執行的嘛

"C:Program FilesMicrosoft SQL ServerXToolsBinnsqllogship.exe" -Restore F4ECF74B-B261-4EE6-9A10-CD669B995D84 -server msnsql

結果如下 :


2019-08-15 12:40:57.70  Retrieved common restore settings. Primary Server: 'MSSQL', Primary Database: 'xxmsdb', Backup Destination Directory: 'L:', File Retention Period: 4320 minute(s)
2019-08-15 12:40:57.70  Retrieved database restore settings. Secondary Database: 'xxmsdb', Restore Delay: 0, Restore All: True, Restore Mode: Standby, Disconnect Users: True, Last Restored File: L:xxmsdb_20190814100001.trn, Block Size: Not Specified, Buffer Count: Not Specified, Max Transfer Size: Not Specified
2019-08-15 12:40:59.48  *** Error: Could not apply log backup file 'L:xxmsdb_20190814101500.trn' to secondary database 'xxmsdb'.(Microsoft.SqlServer.Management.LogShipping) ***
2019-08-15 12:40:59.48  *** Error: 在處理資料庫 'xxmsdb' 的記錄檔時,發生錯誤。如果可以的話,請從備份進行還原。若備份無法使用,可能需要重建記錄檔。
復原時發生錯誤,導致資料庫 'xxmsdb' (5:0) 無法重新啟動。請診斷並修正復原錯誤,或者從已知完好的備份還原。如果不能更正或預期錯誤,請連絡技術支援部門。
RESTORE LOG 正在異常結束。

xxmsdb_20190814101500.trn沒辦法restore
那我就手動進行看看囉~~
哪尼???
這是蝦米狀況阿?????
在這邊工作,發生這種問題
就是開Call給微軟
但突然間有人跟你說
資源不能給BU使用
真是靠北哩............
Log Shipping是在客戶端開會時所提出的建議
縱然可以透過差異備份還原來替代
但總不能打臉自己吧!!
好吧~~只好上谷哥,慢慢爬文了
還真的被我爬到了雷同的狀況
root cause是"交易量太小"
因為我習慣開成standby 唯讀模式
PO文的人開了case問微軟
support 要他們進行CU更新
我只好提出我的解決方式囉


怎麼可能只為了機房搬遷
就去上個CU
當然是採取第一項解決方式
只是....Log Shipping是多久的一項技術了
怎麼會在2014的版本後才出現這個bug哩???
Log Shipping

Oracle Plug / Unplug PDB 來更改資料庫名稱

為了以最短的時間弄出一個環境給AP
由於AP正在資料庫test PDB上進行測試
只好另建testsync PDB 透過OGG 同步資料
其實也是因為test 打補丁時出了一點問題
雖然後來解了
但AP還是心裡頭總有些疙瘩
我是沒差啦!!
趁這個機會測一下新功能

-- drop PDB test
alter pluggable database test close immediate;
DROP PLUGGABLE DATABASE test including datafiles;

-- testsync rename to test
alter pluggable database testsync close immediate;

ALTER PLUGGABLE DATABASE testsync UNPLUG INTO '/tmp/testsync.xml';

DROP PLUGGABLE DATABASE testsync KEEP DATAFILES;

 CREATE PLUGGABLE DATABASE test USING '/tmp/testsync.xml'
 FILE_NAME_CONVERT=('/oradata/testcdb/testsync/','/oradata/testcdb/test/')
  move

 TEMPFILE REUSE;

alter pluggable database test open;

Very GOOD!!好用~~~~


10g data guard 如何解決archive log gap太大,已被清掉的問題

我的環境還蠻常發生的
好加在,要升到18c了
1. On the standby database, stop the managed recovery process (MRP):
可能得先停掉DMON -- ALTER SYSTEM SET dg_broker_start=false scope=both;-- 如果有的話
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2. On the standby database, find the SCN which will be used for the incremental
backup at the primary database:
SQL> SELECT to_char(CURRENT_SCN) FROM V$DATABASE;

3. incremental backup
BACKUP INCREMENTAL FROM SCN 9396571788224 AS COMPRESSED BACKUPSET DATABASE FORMAT '/oradata2/syncdr/DBtandby_2019_0812%U' tag 'DBSTANDBY_2019_0812';

4.Connect to the standby database as the RMAN target, and catalog all incremental backup pieces:
CATALOG START WITH '/oradata2/syncdr/DBStandby_2019_0812'; -- 傳檔

5.
Recover the standby database with the cataloged incremental backup
RMAN> RECOVER DATABASE NOREDO;

6. In RMAN, connect to the primary database and create a standby control file backup:
BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/oradata2/syncdr/DBStandbyCTRL_0812.bck'; -- 傳檔

7.Shut down the standby database and startup nomount:
RMAN> SHUTDOWN;
RMAN> STARTUP NOMOUNT;

8.
In RMAN, connect to standby database and restore the standby control file:
RMAN> RESTORE STANDBY CONTROLFILE FROM '/oradata2/syncdr/DBStandbyCTRL_0812.bck';


11. Shut down the standby database and startup mount:
SQL> SHUTDOWN;
SQL>startup nomount;
SQL>alter database mount standby database;
SQL>alter database recover managed standby database disconnect from session;

I think you should still catch or register log after recovering the standby control file.

Oracle 18c Data Guard 建置

參考底下這一篇一定可以建置出來

Data Guard Physical Standby Setup Using the Data Guard Broker in Oracle Database 18c


DG專書上提到了跟密碼檔相關的事項
是否如書中所說,我不清楚
我自己從以前建置DG就是習慣用拷貝的方式
orapwd


Oracle 官方的文件如是說
Note: Even when you are using the broker, you must ensure that all physical and snapshot standby databases are using a current copy of the password file from the primary database. The copy must be refreshed whenever an administrative privilege (SYSDG, SYSOPER, SYSDBA, and so on) is granted or revoked, and after the password of any user with administrative privileges is changed.
#####今日插入更新2020/01/13##############
剛好在研究12.2 RAC to RAC ADG的建置
仔細地查閱了password 檔案的在DG建置上的需求
只是透過duplicate database from active database
password file會在rman session裡頭
主動幫你傳送到DG Site
其他的建置機制,都只能手動拷貝password 檔
12.1 以後redo shipping作業就要求
DG SITE的password 檔必須是Primary 的拷貝檔
不能是由orapwd指令建出來的檔案
即使密碼一模一樣也不行
這與在起動aux channel 進行duplicate db
所使用的password file不同
這個檔是暫時性的
#####今日插入更新2020/01/13##############
切換其實很簡單,就是一行指令而已
STB就是DR, CDB就是營運套

switchover
















來看看切換之後的狀態
show configuration















寫了一隻塞資料的程式來驗證資料同步
當然是在 DR主機上執行
















來原本的營運套上驗證資料
再把系統切回來吧~~












其實第一次切換的時候
switchover 指令下去後,會有一段時間沒動作
當下會懷疑,是不是有問題
再加上,營運套還在HA的保護下
發現dgbroker會下上資料庫後
遲疑了一下就直接按了Ctrol +C 中斷了
結果兩個資料庫都進入了read only with real apply的模式
我就手動重開兩個資料庫
原DR進入了read write模式
這個時間點其實我沒甚麼頭緒
反正就是試看看能不能重建組態
由營運套把dg broker的組態拿掉
再到DR主機把dg broker的組態建出
只是在DR主機上建出組態所使用的名稱就跟營運套的不同
組態重新建出後,又進行了switchover 及switch back的測試
結果要回來的過程中出現了錯誤


去比對了tnsnames.ora及listener.ora
原來是我筆誤
dgmgrl 寫成了mgrl,難怪找不到
修正之後, 切過來 切過去,都一行switchover 指令就完成了