分析SQL中的DBA

本篇內(nèi)容主要講解“分析SQL中的DBA”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“分析SQL中的DBA”吧!

1.程序備份

場景：一旦程序所在主機故障，需要在新環(huán)境下重新部署程序時，程序備份的作用就體現(xiàn)出來了。

其實我這里程序所連接的底層數(shù)據(jù)庫是Oracle RAC架構(gòu)，可直接在RAC另一個節(jié)點部署一套程序。因為之前程序使用的文件默認(rèn)在/home/oracle下，該目錄還有很多其他與程序無關(guān)的文件，比較混亂，現(xiàn)考慮將程序整理到統(tǒng)一目錄下整體打包，便于備份，遇到故障也可以方便快速重新部署。
我這里統(tǒng)一放置目錄：/home/oracle/baby，并將程序按照當(dāng)前版本號進(jìn)行打包備份，最后拷貝備份的程序包到NAS留存。

1.1 統(tǒng)一放置目錄：/home/oracle/baby

[oracle@jystdrac2 baby]$ pwd
/home/oracle/baby
[oracle@jystdrac2 baby]$ ls -lrth
total 76K
-rw-r--r-- 1 oracle oinstall  36 Dec 22 09:47 d1.sql
-rw-r--r-- 1 oracle oinstall  71 Dec 22 09:47 i1.sql
-rw-r--r-- 1 oracle oinstall  91 Dec 22 09:47 i2.sql
-rw-r--r-- 1 oracle oinstall  59 Dec 22 09:47 u1.sql
-rw-r--r-- 1 oracle oinstall 199 Dec 22 09:47 v1.sql
-rw-r--r-- 1 oracle oinstall 218 Dec 22 09:47 v2.sql
-rw-r--r-- 1 oracle oinstall 396 Dec 22 09:47 v3.sql
-rw-r--r-- 1 oracle oinstall 465 Dec 22 09:47 v4.sql
-rw-r--r-- 1 oracle oinstall 132 Dec 22 09:47 v_estimate.sql
-rwxr-xr-x 1 oracle oinstall 302 Dec 22 09:54 baby_delete.sh
-rwxr-xr-x 1 oracle oinstall 296 Dec 22 09:55 baby_insert.sh
-rwxr-xr-x 1 oracle oinstall 335 Dec 22 09:55 baby_insert_diy.sh
-rwxr-xr-x 1 oracle oinstall 545 Dec 22 09:56 baby_help.sh
-rwxr-xr-x 1 oracle oinstall 305 Dec 22 09:57 baby_update.sh
-rwxr-xr-x 1 oracle oinstall 293 Dec 22 09:57 baby_view.sh
-rwxr-xr-x 1 oracle oinstall 252 Dec 22 09:58 baby_view_diy.sh
-rw-r--r-- 1 oracle oinstall 244 Dec 22 13:30 bash_profile
-rw-r--r-- 1 oracle oinstall 273 Dec 26 09:10 backup_exp_t_baby.sh
-rw-r--r-- 1 oracle oinstall 154 Dec 26 09:53 readme
[oracle@jystdrac2 baby]$ cd ..

1.2 將程序按照當(dāng)前版本號進(jìn)行打包備份

[oracle@jystdrac2 ~]$ tar -zcvf baby_v2.02.tar.gz baby/
baby/
baby/readme
baby/u1.sql
baby/v4.sql
baby/baby_view_diy.sh
baby/d1.sql
baby/v3.sql
baby/baby_update.sh
baby/v2.sql
baby/v_estimate.sql
baby/i1.sql
baby/bash_profile
baby/baby_insert_diy.sh
baby/baby_insert.sh
baby/i2.sql
baby/v1.sql
baby/baby_help.sh
baby/baby_view.sh
baby/baby_delete.sh
baby/backup_exp_t_baby.sh
[oracle@jystdrac2 ~]$ ls -lrth baby_v2.02.tar.gz 
-rw-r--r-- 1 501 1000 1.9K Dec 26 11:46 baby_v2.02.tar.gz

1.3 最后拷貝備份的程序包到NAS留存

[oracle@jystdrac2 ~]$ cp baby_v2.02.tar.gz /public/backup/

2.數(shù)據(jù)備份

場景：上面已經(jīng)做了程序備份，但出現(xiàn)故障時我們只恢復(fù)程序是不夠的，還需要之前產(chǎn)生的業(yè)務(wù)數(shù)據(jù)。所以我們還需要業(yè)務(wù)數(shù)據(jù)的備份。

可以采用exp/expdp定時邏輯備份，因為我這里數(shù)據(jù)量很小，所以直接采用更簡單的exp備份。
比如每天12點使用exp備份出當(dāng)前表t_baby的數(shù)據(jù)：
設(shè)置crontab定時任務(wù)：

[oracle@jystdrac2 ~]$ crontab -l
0 12 * * * /bin/sh /home/oracle/baby/backup_exp_t_baby.sh

exp備份腳本：

[oracle@jystdrac2 ~]$ cat /home/oracle/baby/backup_exp_t_baby.sh
backupdate=`date +%Y%m%d`
export ORACLE_SID=demo2
export ORACLE_BASE=/opt/app/oracle
export ORACLE_HOME=/opt/app/oracle/product/11.2.0/dbhome_1
export PATH=$PATH:$ORACLE_HOME/bin
exp test/test tables=t_baby file=/public/backup/t_baby_$backupdate.dmp log=/public/backup/t_baby_$backupdate.log

備份出的文件類似這樣：

[oracle@jystdrac2 backup]$ ls -lrth t_baby*
-rw-rw-rw- 1 501 1000 626 Dec 26 12:00 t_baby_20191226.log
-rw-rw-rw- 1 501 1000 16K Dec 26 12:00 t_baby_20191226.dmp

3.數(shù)據(jù)實時同步

場景：如果只有上面步驟的定時邏輯備份，其實還是無法滿足完全的數(shù)據(jù)恢復(fù)的。

比如今天中午12點做了備份，晚上18點出現(xiàn)了故障，數(shù)據(jù)丟失。通過邏輯備份只能恢復(fù)到今天中午12點的數(shù)據(jù)，而12點到18點之間的數(shù)據(jù)將會丟失。
如果采用物理RMAN備份呢？其實也同樣存在這樣的問題，因為日志歸檔并不是實時的，如果故障不可恢復(fù)，聯(lián)機重做日志也丟失，RMAN也是不完全恢復(fù)到最近的歸檔日志，也同樣會有丟失部分?jǐn)?shù)據(jù)的風(fēng)險。

那怎么辦呢？如何進(jìn)行數(shù)據(jù)實時同步到另外的環(huán)境呢？目前可以想到兩種主流的解決方案：

• 1)數(shù)據(jù)庫DG實時同步

• 2)數(shù)據(jù)表OGG同步

數(shù)據(jù)庫DG實時同步是物理的方式，數(shù)據(jù)表OGG同步是邏輯的方式。
一般情況下，如果兩個方案只能選擇其一時，我們會強烈推薦客戶選用物理方式的實時同步，因為邏輯方式按經(jīng)驗來看遇到的問題遠(yuǎn)比物理方式要高。
而在我這個場景下，數(shù)據(jù)量很小，其實完全可以二者都選擇。
至于DG和OGG環(huán)境搭建的部分我這里不再詳細(xì)展開，如有問題，可參考之前的文章：

• 模擬生產(chǎn)搭建Standby RAC實驗環(huán)境(11.2.0.4 DG)

• OGG學(xué)習(xí)筆記02-單向復(fù)制配置實例

4.已知問題解決

在這個計算喂奶間隔的程序投入使用了一段時間后，還發(fā)現(xiàn)一些問題亟待解決：

4.1 系統(tǒng)時間不準(zhǔn)確
系統(tǒng)運行幾天后，操作系統(tǒng)的時間會和真實時間相差幾分鐘，這個暫時通過定時同步阿里云的NTP服務(wù)器來解決。

--使用ntpdate命令與阿里云時間服務(wù)器(ntp2.aliyun.com)同步
[root@jystdrac1 ~]# date
Sun Dec 22 08:48:51 CST 2019
[root@jystdrac1 ~]# ntpdate ntp2.aliyun.com
22 Dec 08:52:31 ntpdate[24481]: step time server 203.107.6.88 offset 206.232030 sec
[root@jystdrac1 ~]# date
Sun Dec 22 08:52:35 CST 2019
--使用crontab定時，每小時與阿里云時間服務(wù)器同步一次，同步日志追加到/tmp/ntpdate.log日志文件
crontab -l
0 * * * * ntpdate ntp2.aliyun.com >> /tmp/ntpdate.log

當(dāng)然，這里其實還可以設(shè)置NTP微調(diào)(-x)模式，保證RAC穩(wěn)定性不受其調(diào)整的影響。

4.2 數(shù)據(jù)一致性問題
這個也可以說是程序設(shè)計時的bug。
現(xiàn)象：當(dāng)前程序連接的數(shù)據(jù)庫底層是單實例，或始終在RAC的同一個節(jié)點上運行，就不會有任何問題；但如果在RAC的兩個節(jié)點交叉運行插入數(shù)據(jù)，序列就會出現(xiàn)問題導(dǎo)致計算結(jié)果產(chǎn)生訛誤。
先稱之為是RAC環(huán)境下sequence的問題解決：

比如：在節(jié)點1插入記錄，ID為235，再到節(jié)點2插入記錄，ID卻為192.

[oracle@jystdrac2 ~]$ i
Insert a row using current time:
1 row created.
Commit complete.
View Today's Result:
        ID FEED_TIME   L   LAG(min)     LAG(h)
---------- ----------- - ---------- ----------
       192 12-26 18:21 N       5689      94.82
       227 12-26 02:22 N        225       3.75
       228 12-26 04:48 N        146       2.43
       229 12-26 07:31 N        164       2.73
       230 12-26 10:02 N        151       2.51
       231 12-26 11:49 N        107       1.79
       232 12-26 14:10 N        141       2.34
       233 12-26 17:38 N        208       3.47
       234 12-26 18:18 N         41        .68
       235 12-26 18:19 N          0        .01
10 rows selected.

可以看到在節(jié)點2后插入的記錄ID值反而小，導(dǎo)致程序本身間隔計算也出現(xiàn)了訛誤，明顯這樣是有問題的。
其實問題也非常明顯，實例1和實例2獲取s1的sequence是不連續(xù)的，分別在兩個實例上查詢：

--實例1:
test@DEMO> select s1.nextval from dual;
   NEXTVAL
----------
       239
--實例2:
test@DEMO> select s1.nextval from dual;
   NEXTVAL
----------
       193

查詢下sequence的創(chuàng)建語句：

test@DEMO> select dbms_metadata.get_ddl('SEQUENCE','S1') from dual;
DBMS_METADATA.GET_DDL('SEQUENCE','S1')
--------------------------------------------------------------------------------
   CREATE SEQUENCE  "TEST"."S1"  MINVALUE 1 MAXVALUE 9999999999999999999999999999 INCREMENT BY 1 STA
RT WITH 241 CACHE 20 NOORDER  NOCYCLE

可以看到序列默認(rèn)是NOORDER，如果設(shè)為ORDER，測試反復(fù)在兩個實例上交叉讀序列的nextval，都能保證序列值是順序的，就不會再出現(xiàn)最初的情況。
所以解決方案就是重建sequence s1，修改為ORDER。

drop SEQUENCE s1;
CREATE SEQUENCE s1 MINVALUE 1 MAXVALUE 9999999999999999999999999999 INCREMENT BY 1 START WITH 261 CACHE 20 ORDER  NOCYCLE;

再次驗證(select s1.nextval from dual;)，確認(rèn)此時序列是有序的：

--實例1:
test@DEMO> select s1.nextval from dual;
   NEXTVAL
----------
       261
--實例2:
test@DEMO> select s1.nextval from dual;
   NEXTVAL
----------
       262

但還需要注意如果將序列改為ORDER，在實際業(yè)務(wù)壓力大時很可能會造成嚴(yán)重性能問題，這估計也是不加任何參數(shù)創(chuàng)建的sequence默認(rèn)就是NOORDER的原因。

到此，相信大家對“分析SQL中的DBA”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！