目前程序從功能上其實已經完全滿足客戶（當然我這里的客戶都是指媳婦兒_）需求，具體可參考：
那么本篇 使用SQL計算寶寶每次吃奶的時間間隔 - Part3：保障數據安全 存在的意義在哪呢？
原因很簡單，就是因為我們作為技術人，實際需要考慮的要更多。比如本篇從數據保障層面，我們必須要考慮數據的一致性和安全性等。而且我們要很清楚，這些需求並不是客戶不關注不需要，很可能只是因為客戶並不知道可能會出現什么問題，不知道如果一旦出現硬件損壞、各類故障導致數據損壞或出現訛誤時，我們目前的情況是恢復不了的，到時就只能被說成是技術差，甚至連帶背各種鍋。在這樣的場景下，技術人再去狡辯說客戶開始也壓根沒提這些安全性的數據保障需求啊，是沒有人會站在技術這一邊的，因為這些客戶考慮不到的，恰恰是需要你來主動去提出去建議去實施的，這也是體現一位技術人專業性的關鍵所在。
下面以幾個維度來展開說明：
1.程序備份
場景：一旦程序所在主機故障，需要在新環境下重新部署程序時，程序備份的作用就體現出來了。 其實我這里程序所連接的底層數據庫是Oracle RAC架構，可直接在RAC另一個節點部署一套程序。因為之前程序使用的文件默認在/home/oracle下，該目錄還有很多其他與程序無關的文件，比較混亂，現考慮將程序整理到統一目錄下整體打包，便於備份，遇到故障也可以方便快速重新部署。 我這里統一放置目錄：/home/oracle/baby，並將程序按照當前版本號進行打包備份，最后拷貝備份的程序包到NAS留存。1.1 統一放置目錄：/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 將程序按照當前版本號進行打包備份
[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.數據備份
場景：上面已經做了程序備份，但出現故障時我們只恢復程序是不夠的，還需要之前產生的業務數據。所以我們還需要業務數據的備份。 可以采用exp/expdp定時邏輯備份，因為我這里數據量很小，所以直接采用更簡單的exp備份。 比如每天12點使用exp備份出當前表t_baby的數據： 設置crontab定時任務：[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.數據實時同步
場景：如果只有上面步驟的定時邏輯備份，其實還是無法滿足完全的數據恢復的。 比如今天中午12點做了備份，晚上18點出現了故障，數據丟失。通過邏輯備份只能恢復到今天中午12點的數據，而12點到18點之間的數據將會丟失。 如果采用物理RMAN備份呢？其實也同樣存在這樣的問題，因為日志歸檔並不是實時的，如果故障不可恢復，聯機重做日志也丟失，RMAN也是不完全恢復到最近的歸檔日志，也同樣會有丟失部分數據的風險。那怎么辦呢？如何進行數據實時同步到另外的環境呢？目前可以想到兩種主流的解決方案：
- 1)數據庫DG實時同步
- 2)數據表OGG同步
數據庫DG實時同步是物理的方式，數據表OGG同步是邏輯的方式。
一般情況下，如果兩個方案只能選擇其一時，我們會強烈推薦客戶選用物理方式的實時同步，因為邏輯方式按經驗來看遇到的問題遠比物理方式要高。
而在我這個場景下，數據量很小，其實完全可以二者都選擇。
至於DG和OGG環境搭建的部分我這里不再詳細展開，如有問題，可參考之前的文章：
4.已知問題解決
在這個計算喂奶間隔的程序投入使用了一段時間后，還發現一些問題亟待解決： **4.1 系統時間不准確** 系統運行幾天后，操作系統的時間會和真實時間相差幾分鍾，這個暫時通過定時同步阿里雲的NTP服務器來解決。--使用ntpdate命令與阿里雲時間服務器(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定時，每小時與阿里雲時間服務器同步一次，同步日志追加到/tmp/ntpdate.log日志文件
crontab -l
0 * * * * ntpdate ntp2.aliyun.com >> /tmp/ntpdate.log
當然，這里其實還可以設置NTP微調(-x)模式，保證RAC穩定性不受其調整的影響。
4.2 數據一致性問題
這個也可以說是程序設計時的bug。
現象：當前程序連接的數據庫底層是單實例，或始終在RAC的同一個節點上運行，就不會有任何問題；但如果在RAC的兩個節點交叉運行插入數據，序列就會出現問題導致計算結果產生訛誤。
先稱之為是RAC環境下sequence的問題解決：
比如：在節點1插入記錄，ID為235，再到節點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.
可以看到在節點2后插入的記錄ID值反而小，導致程序本身間隔計算也出現了訛誤，明顯這樣是有問題的。
其實問題也非常明顯，實例1和實例2獲取s1的sequence是不連續的，分別在兩個實例上查詢：
--實例1:
test@DEMO> select s1.nextval from dual;
NEXTVAL
----------
239
--實例2:
test@DEMO> select s1.nextval from dual;
NEXTVAL
----------
193
查詢下sequence的創建語句：
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
可以看到序列默認是NOORDER，如果設為ORDER，測試反復在兩個實例上交叉讀序列的nextval，都能保證序列值是順序的，就不會再出現最初的情況。
所以解決方案就是重建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;)，確認此時序列是有序的：
--實例1:
test@DEMO> select s1.nextval from dual;
NEXTVAL
----------
261
--實例2:
test@DEMO> select s1.nextval from dual;
NEXTVAL
----------
262
但還需要注意如果將序列改為ORDER，在實際業務壓力大時很可能會造成嚴重性能問題，這估計也是不加任何參數創建的sequence默認就是NOORDER的原因。