JDE - 更改Web介面的圖檔為顯示environment

以DV環境為例，原本的登入畫面長的是這樣，無法分別正要登入哪個環境。

loging web server，用下列find指令找到要替換的圖檔:

[root@e1oas02 images]# find /u01 -name 'fndsscorp.gif'|grep DV
/u01/OracleAS_1/j2ee/DV_e1oas02/applications/DV_e1oas02/webclient/share/images/fndsscorp.gif
/u01/OracleAS_1/j2ee/DV_e1oas02/applications/DV_e1oas02/webclient/share/images/login/fndsscorp.gif

備份原版圖檔:

[root@e1oas02 images]# cd /u01/OracleAS_1/j2ee/DV_e1oas02/applications/DV_e1oas02/webclient/share/images

[root@e1oas02 images]# cp -p ./fndsscorp.gif ./fndsscorp.gif.bak

[root@e1oas02 images]# cp -p ./login/fndsscorp.gif ./login/fndsscorp.gif.bak

用修改過的圖檔，覆蓋掉fndsscorp.gif:

[root@e1oas02 images]# cp ./DV_e1oas02.gif ./fndsscorp.gif

[root@e1oas02 images]# cp ./DV_e1oas02.gif ./login/fndsscorp.gif

再次檢查登入畫面，這樣就容易做判斷，user也不會在錯誤的環境敲單了。

如果是WebLogic Server，則環境圖檔的位置如下:
/u01/oracle/Middleware/user_projects/domains/PD_e1wls04/servers/PY900_e1wls04/stage/PY_e1wls04/app/webclient.war/share/images/login/fndsscorp.gif
/u01/oracle/Middleware/user_projects/domains/PD_e1wls04/servers/PY900_e1wls04/stage/PY_e1wls04/app/webclient.war/share/images/fndsscorp.gif

Oracle Database 11g - Controlling Archive Lag

如果你有使用Oracle standby db，且使用ARCH來傳送redo log，有個很重要的參數要留意。


SQL> show parameter ARCHIVE_LAG_TARGET;

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
archive_lag_target                   integer
0
SQL>  alter system set ARCHIVE_LAG_TARGET = 1800 scope= both;

System altered.

SQL> show parameter ARCHIVE_LAG_TARGET;

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
archive_lag_target                   integer
1800

這樣即完成archive_lag_target參數的設定。

設定完成後，可以達到什麼樣的效果呢?
如果一個redo log file 是200MB，假設在夜間時段系統的trx量很小，可能五個小時的trx量，還沒有到達200MB，自然就不會產生log switch，redo log就不會在standby site 做apply。如此一來，standby db 和primary db的資料時間差就會很久。以這個例子，透過archive_lag_target參數的設定，即可以限定最久每30分鐘一定要log switch一次，亦即最少每30分鐘會傳送redo log 到standby db。


ps, 如果有用Data Guard，則須在data guard broker中做設定
EDIT DATABASE 'DGTEST_P' SET PROPERTY 'ArchiveLagTarget' = '1800';

Oracle Database 11g - enable flashback database

如果database發生logical data corruption 或是 人為的錯誤(譬如誤刪資料，誤改資料)，Oracle 11g有個很好用的功能，叫做flashback database，可以回復到某個還原點，或是某個SCN，速度會比使用RMAN做復原來個快。

Example:
FLASHBACK DATABASE TO RESTORE POINT 'before_install';
FLASHBACK DATABASE TO SCN 202333;

前提:
1. database要在archivelog mode
2. fast recovery area 要是enabled

設定步驟:
SQL> shutdown immediate
SQL> startup mount
SQL> set line 120
SQL> column db_unique_name format A20

SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 scope=both;  # 3天
System altered.
SQL> recover managed standby database cancel;
Media recovery complete.

SQL> ALTER DATABASE FLASHBACK ON;

Database altered.
SQL> select DB_UNIQUE_NAME,FORCE_LOGGING,FLASHBACK_ON from v$database;
DB_UNIQUE_NAME       FORCE_LOG FLASHBACK_ON
-------------------- --------- ------------------------------------------------------
DGTEST_S             YES       YES
SQL> show parameter DB_FLASHBACK_RETENTION_TARGET
NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
db_flashback_retention_target        integer                           4320
SQL> alter database open;

以上，完成flashback database的設定。
記得要 monitor Flash Recovery Area 的使用量，不要讓他爆了。

SQL> select * from v$recovery_file_dest;

SQL> select * from v$recovery_area_usage;

飲鴆止渴?

這周聽說一個馬路消息，某NB OEM/ODM 大廠，將其ERP系統資料庫，從Oracle升級到MS SQL Server。我很直覺的想法是，這樣真的可以降低TCO? 還是資訊科技的發展真的一日千里，database已經可完全的self maintenance and tuning了? 亦或是CIO也是四年一任，七傷拳效果好，做點績效出來先?

Oracle 11g data guard 的 redo log transport compression 效果

11gR2之後，所有的redo log transport都可以先壓縮後傳送。
如果database上有足夠的CPU resource啟動此功能也非常簡單，透過一個指令，即可完成。

DGMGRL> edit database 'DB_UNIQUE_NAME' SET PROPERTY 'RedoCompression' = ENABLE;

效果非常的好，可以降低網路的傳輸量，加快redo log的傳送，有圖有真相。

忘記 weblogic administration console的密碼 -- 如何重置?

1. 確認WebLogic instance 是關閉的.

2. 執行setDomainEnv.sh

3. cd $WL_HOME/user_projects/domains/base_domain/security

4. Run：
java weblogic.security.utils.AdminAccount admin_user admin_pass .

依需求更改 “admin_user”和“admin_pass”.

不要忘記 “.” 在上述命令的結束，它是必需的.

5. 執行該命令後，確認“文件”DefaultAuthenticatorInit.ldift“已經更新.

6. 從“LDAP”文件夾中刪除以下文件：

cd WL_HOME/user_projects/domains/base_domain/servers/AdminServer/data/ldap
rm DefaultAuthenticatormyrealmInit.initialized


7. cd $DOMAIN_HOME/servers/AdminServer/security

8. vi boot.properties 為新密碼

9. 啟動WebLogic Server（Weblogic服務器將加密你的密碼）

P2V(虛擬化) JDE B733 Server

    上週，使用者抱怨，因為要查帳，才發現很久沒有受到關心的JDE733環境不太穩定，job丟到enterprise queue時不會執行。shit happens again，於是當然又輪到我這個CNC出馬來擦一擦。

    明察暗訪後，發現還有一台fat client可以開啟，也可以submit local job，趕緊shutdown 全部的環境，使用了不起的VMware converter來綠化這個老東西。

依序convert

1. Fat-client --> VMware Player
2. Enterprise Server(轉換完成後兩個小時，DELL1800的power就掛點) --> ESXi
3. Deployment Server(也是DELL 1800，主機板已經壞了) --> ESXi

轉換完成，請財務user確認，可以query，可以submit local，都沒有問題。好了，感謝老天，淘汰兩台耗電的老主機，一台PC，虛擬化順便節能省碳。再一個cold backup 到LTO3，就算幫這個老環境延壽十年了。