墨天輪原文鏈接：https://www.modb.pro/db/12007?ywm
華爲GaussDB OLTP 100 的安裝是通過 Python 腳本執行的，通過運行 install.py 創建數據庫。
華爲GaussDB OLTP 100 的安裝是通過 Python 腳本執行的，通過運行 install.py 創建數據庫。
在第一次安裝時，遇到如下問題，輸出日誌顯示，數據庫實例啓動失敗：
[root@localhost ]# python install.py -U omm:dbgrp -R /opt/gaussdb/app -D /opt/gaussdb/data -C LSNR_ADDR=127.0.0.1,192.168.1.121 -C LSNR_PORT=1888
Checking runner.
Checking parameters.
End check parameters.
Checking user.
End check user.
Checking old install.
End check old install.
Checking kernel parameters.
Checking directory.
Checking integrality of run file…
Decompressing run file.
Setting user env.
Checking data dir and config file
Initialize db instance.
Creating database.
Error: Can not get instance ‘/opt/gaussdb/data’ process pid,The detailed information: 'instance startup failed ’
Please refer to install log “/home/omm/zengineinstall.log” for more detailed information.
從日誌可以看出，默認初始化的實例名稱是 zengine ，也就是 Z 引擎的含義。
前臺輸出的錯誤信息是：instance startup failed 。
那麼實例啓動失敗的真實原因是什麼呢？
在 GaussDB 數據庫安裝失敗之後，會回滾所有操作，檢查運行日誌，可以找到具體的錯誤原因。
從以下日誌提示中，可以檢查數據庫的初始參數設置，最後的提示是創建SGA失敗：
[root@localhost ~]# cd /opt/gaussdb/log/run
[root@localhost run]# ls
zengine.rlog
[root@localhost run]# more zengine.rlog
UTC+8 2019-11-22 15:36:47.885|ZENGINE|00000|77309437941|INFO>[LOG] file ‘/opt/gaussdb/data/log/zenith_alarm.log’ is added [srv_param.c:488]
UTC+8 2019-11-22 15:36:47.885|ZENGINE|00000|26613|INFO>[LOG] file ‘/opt/gaussdb/data/log/run/zengine.rlog’ is added [cm_log.c:643]
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] LSNR_ADDR = 127.0.0.1,192.168.1.121
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] LSNR_PORT = 1888
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] DATA_BUFFER_SIZE = 2G
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] SHARED_POOL_SIZE = 1G
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] LOG_BUFFER_SIZE = 64M
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] LOG_BUFFER_COUNT = 8
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] TEMP_BUFFER_SIZE = 1G
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] SESSIONS = 1500
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] DBWR_PROCESSES = 8
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] INSTANCE_NAME = zenith
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|INFO>[PARAM] ENABLE_SYSDBA_LOGIN = TRUE
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|206158456821|INFO>starting instance(nomount)
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|ERROR>GS-00001 : Failed to allocate 4592381952 bytes for sga [srv_sga.c:170]
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|ERROR>failed to create sga
UTC+8 2019-11-22 15:36:47.917|ZENGINE|00000|26613|ERROR>Instance Startup Failed
注意，我們在這裏發現了GaussDB 的第一號錯誤： GS-00001 。這個錯誤提示是無法分片足夠的 SGA 內存。對於這個錯誤，可以通過定義安裝時的內存參數，或者擴大主機內存超過 4GB 即可。
我們可以對比一下 Oracle 的第一號錯誤，ORA-00001 是唯一約束衝突：
ORA-00001: unique constraint (string.string) violated
Cause: An UPDATE or INSERT statement attempted to insert a duplicate key. For Trusted Oracle configured in DBMS MAC mode, you may see this message if a duplicate entry exists at a different level.
Action: Either remove the unique restriction or do not insert the key.
從 GaussDB 和 Oracle 數據庫的對比來看，GaussDB 的 第一號 錯誤，突出的是從數據庫入手和着眼；而 Oracle 的 第一號錯誤，則是從應用和 數據入手的。
那麼在 GaussDB 中，Oracle 的第一號錯誤排在什麼位置呢？我們做個測試：
SQL> create unique index idx_enmo_id on enmo(id);
Succeed.
SQL> insert into enmo values(1,‘EYGLE’);
1 rows affected.
SQL> insert into enmo values(1,‘EYGLE’);
GS-00729, Unique constraint violated, index IDX_ENMO_ID, duplicate key 1
在 GaussDB 中，唯一約束衝突的問題，排在第 729 號上。
關於 GaussDB 的學習資料，進一步可以參考 墨天輪：