9i與11g在SQL中有使用disticnt的處理方式不同

因為Database的版本由9i升級為11g,在測試的過程中發現某些報表在9i與11g顯示出來的排序不一樣。
但是報表使用的SQL及程式都是一樣的,在回報顧問之後,得知SQL中有使用distinct後,但是9i與11g在處理上有不一樣的地方。
而11g有一個參數optimizer_features_enable可以改為9i的處理方式,但是多少會影響效能,測試步驟如下:

11g預設的值
SQL> select name,value from v$parameter where name='optimizer_features_enable';

NAME                                VALUE
----------------------------------- --------------------
optimizer_features_enable           11.2.0.4


執行下列SQL後可以發現資料並未排序,執行計劃可以知道11g使用HASH (UNIQUE)
SQL> select distinct a from tmp_ddd where rownum<=10;

A
------------------------------------------------------------------------------
703-264
703-272
703-273
703-438
703-398
703-265
703-262
703-263
703-437
703-274

10 rows selected.


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=4 Card=10 Bytes=80
          )

   1    0   HASH (UNIQUE) (Cost=4 Card=10 Bytes=80)
   2    1     COUNT (STOPKEY)
   3    2       TABLE ACCESS (FULL) OF 'TMP_DDD' (TABLE) (Cost=3 Card=
          337 Bytes=2696)

修改optimizer_features_enable為9.2.0
SQL> alter system set optimizer_features_enable='9.2.0';

System altered.

查詢設定是否成功
SQL> select name,value from v$parameter where name='optimizer_features_enable';

NAME                                VALUE
----------------------------------- --------------------
optimizer_features_enable           9.2.0

再執行相同的SQL,可以發現資料已自動排序,執行計畫顯示為SORT (UNIQUE)
SQL> select distinct a from tmp_ddd where rownum<=10;

A
-------------------------------------------------------------------------------
703-262
703-263
703-264
703-265
703-272
703-273
703-274
703-398
703-437
703-438

10 rows selected.


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=49 Card=10 Bytes=80)
   1    0   SORT (UNIQUE) (Cost=49 Card=10 Bytes=80)
   2    1     COUNT (STOPKEY)
   3    2       TABLE ACCESS (FULL) OF 'TMP_DDD' (TABLE) (Cost=2 Card=
          337 Bytes=2696)

Report Builder 3.0連接Oracle時出現ORA-12145

在開發Report Builder 3.0的報表時,設定連接Oracle資料庫並且測試,結果出現下列訊息:
ORA-12154: TNS:could not resolve the connect identifier specified
因為非常確定Tnsname沒有設定錯誤,其他的工具也都可以正常連線Oracle。

最後用ProcessExplorer去追踨Report Builder,發現它是由C:\Program Files (x86)…所啟動的,
原來是因為作業系統是64bit,所以Report Builder安裝到C:\Program Files (x86)目錄下,
而Report Builder在連接Oracle時,對於「(」、「)」無法正確識別,以致錯誤產生,
只要把程式改安裝到其他的目錄下就正常連線了。


EBS停用倉庫(Inactive/Disable Subinventory)

原本講好新增一個倉庫A20,在EBS上也設定好了,現在卻又因為上級不同意而打住。
幸好還沒有任何的庫存量在此倉庫中,只要到INV-->Setup-->Organizations-->Subinventories
壓上停用日期就好了。

EBS 的File-->Export無法使用,畫面直接關掉

 今天在EBS上要Export一個forms的資料時(如下圖),Forms的 Export完成後,存檔畫面閃一下就不見。
作業系統是win7、IE8

看不見下圖的存檔畫面,IE閃一下就不見了。

原來是IE的安全性選項擋住了,調整如下:
先確認EBS的網址在在哪一個等級,如下圖是在「信任的網站」

開啟「工具」--> 「網際網路選項」
選擇「信任的網站」,再按下「自訂等級」

找到「自動提示下載檔案」、「檔案下載」的選項,並確定設定為「啟用」就正常了。


FND_LOBS的欄位program_name:export、FNDATTCH

EBS的表格FND_LOBS,有一個欄位program_name,其中兩種:export、FNDATTCH說明如下。
而內容則是存在欄位FILE_DATA(BLOB)。

EBS在上傳檔案時會(如下圖)會在FND_LOBS的program_name填入FNDATTCH。

而在下載檔案時(如下圖)則會在program_name填入export

Command Line指令太長換行符號

Dos用「^」來換行,例如:dir /A
C:\ di^
More? r /A

Linux、Solaris、HP-UX等是用「/」來換行,例如:ls -ld export
bash-3.2# ls -l\
> d export

EBS 11i刪除Workflow Notifications(WF_NOTIFICATIONS)的unsent email

查出有未處理完成的mail
select notification_id, status, mail_status, begin_date
        from WF_NOTIFICATIONS
        where status = 'OPEN' and mail_status = 'MAIL';

的把WF_NOTIFICATIONS的欄位mail_status狀態update為sent
update WF_NOTIFICATIONS set mail_status = 'SENT' where mail_status = 'MAIL';

登入AP Server,執行wfntfqup.sql刪除WF_notifications_out表格裏的未處理mail
$ cd $FND_TOP/patch/115/sql/wfntfqup.sql
$ sqlplus  apps/XXXXX  @wfntfqup.sql  apps  [apps_password]  applsys;

參考資料
ID 372933.1 How to purge e-mail notifications from the workflow queue so the e-mail is not sent

Solaris 10 修改命令提示字元

因為原本的HP-UX登入後是提示主機名:絕對路徑,如:hp01:/etc>
現在系統改為Solaris後,提示字元就變成「bash-3.2$」,有人反應太精簡了。

其實更改命令提示字元就是設定PS1變數,可以把它加到.profile或是/etc/.login。

更改為主機名:絕對路徑,如:hp01:/etc>,語法如下:
PS1='${HOSTNAME}:${PWD}> ';  export PS1
結果:SOL01:/>

更改為Linux的提示字元,語法如下:
PS1='[\u@\h \W]$ ' ; export PS1
結果:[root@SOL01 /]$

顯示出時間,語法如下(\t時間):
PS1="\u@\h [\t]> " ; export PS1
結果:root@SOL01 [16:57:36]>

參數:
\u    帳號
\h    主機名
\W    當前的目錄
\t    時間

另外有一個網站可以利用直覺式拖拉的方式,自訂想要的提示字元,不僅可以預覽還可以自動產生語法。
網址:http://xta.github.io/HalloweenBash/

Netterm無法在vi編輯模式下無法使用方向鍵

因為系統將由HP-UX改為Solaris,同事發現習慣使用的Netterm 4.2.9無法在vi編輯模式下使用方向鍵。
後來得知原本HP-UX也是無法使用方向鍵,但是更改了一些設定後就可以使用,原本以為設定在Netterm上,
結果找不到可以設定方向鍵定義的地方,原來前人修改的是作業系統上的定義。

因為HP-UX可以正常使用方向鍵,所以先從HP-UX下載出定義檔:
HP-UX# infocmp > vt100_code.txt

再將vt100_code.txt複製Solaris上,再執行下列語法匯入定義檔:
Solaris#  tic vt100_code.txt

請同事重新測試成功,下面是vt100_code.txt的資料內容,可見都是設定按鍵的值:
值的定義可能要再找google看看能不能找的到。

# Reconstructed via infocmp from file: /usr/share/lib/terminfo/v/vt100
vt100|vt100-am|dec vt100 (w/advanced video),
bce, bw, ccc, chts, cpix, crxm, da, daisy, db, eo,
eslok, gn, hc, hls, hs, hz, in, km, lpix, mc5i,
ndscr, npc, nrrmc, nxon, os, sam, ul, xhp, xhpa, xsb,
xt, xvpa,
cols#80, it#8, lines#24, vt#3,
bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
clear=\E[H\E[J$<50>, cr=\r, csr=\E[%i%p1%d;%p2%dr,
cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n,
cuf=\E[%p1%dC, cuf1=\E[C$<2>,
cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA,
cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, home=\E[H,
ht=\t, hts=\EH, ind=\n, ka1=\EOq, ka3=\EOs, kb2=\EOr,
kbs=\b, kc1=\EOp, kc3=\EOn, kcub1=\E[D, kcud1=\E[B,
kcuf1=\E[C, kcuu1=\E[A, kdch1=\E[3~, kf0=\EOp,
kf1=\EOq, kf10=\EOp, kf2=\EOr, kf3=\EOs, kf4=\EOt,
kf5=\EOu, kf6=\EOv, kf7=\EOw, kf8=\EOx, kf9=\EOy,
khome=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~,
rc=\E8, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O,
rmso=\E[m$<2>, rmul=\E[m$<2>,
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;,
sgr0=\E[m^O$<2>, smacs=^N, smso=\E[1;7m$<2>,
smul=\E[4m$<2>, tbc=\E[3g,

利用封包擷取程式(Wireshark)取得Telnet登入的帳號及密碼

Telnet在傳輸的過程中並未加密內容,也就是以明文傳送,雖然已經是眾所皆知,但是今天還是做個簡單的駭客實驗,也可以順便學習Wireshark的使用。

先從Wireshark的官網下載程式並安裝,也就是跟著下一步就可以了,要注意的是出現下面的安裝視窗時,把選項勾選,一併安裝WinCap

安裝完成後開啟程式,在程式視窗中先選擇一個要被擷取的網卡後按「Start」就可以了,
例如我的作業系統是Win7,主要的網路是「區域連線」,所以我就點選「區域連線」,再按「Start」

收集封包一段時間後,直接按下「紅色正方形」的按鈕就可以停止擷取,Wireshark會擷取所有通過「區域連線」的封包。

找到Telnet的封包後(也可以設定Filter為telnet,以便快速篩選),按滑鼠右鍵,選擇「Follow TCP Stream」,
Wireshark會自動合併相關封包的內容

如下圖所示,擷取到的Telnet封包不僅會顯示帳號密碼,還能看到操作的過程

而下圖是擷取以SSH登入的封包,內容全被加密,無法得知帳號及密碼



google首頁的數位版魔術方塊

為紀念魔術方塊發明40周年(2014/5/19),google在首頁放上數位版魔術方塊(Magic Cube),
看到後一時興起就來玩看看,單用滑鼠操作果然沒有那麼順手,我是用簡易解法(我也不會速解法)完成它。
其實還蠻有趣的,平時都是以「面」對準自己,數位版卻是「角」對準自己,不同的角度看事情,
果然視野就會不一樣,因為我不是背公式,所以是不是「面」對準我影響不大,
反倒是找顏色及點錯就花了不少的步驟,不過好玩就好了。


Outlook 2010查看郵件的原始檔頭

因為ERP有自行撰寫程式來寄送Mail,所以如果收到Mail,表示有問題需要處理。
而今天收到一封已經處理過的Mail,想著真是奇怪,已處理完應該就不會再發送。
但是從主旨與寄件者來看,的確是ERP發出的Mail,於是從郵件的檔頭試著找出問題。

Outlook 2010的信件要查看信件的原始檔頭必須先將信件開啟,再由「檔案」->「內容」
開啟視窗後,在最下面的「網際網路標題」內就可以找到,如下圖:



由原始檔頭終於找出問題,來源的IP是測試ERP主機,並非是正式ERP的主機,
只是因為該程式開發時,固定主旨與寄件者,所以分辨不出是由誰發送出去的。

EBS 11i & DB 11gR2--PURGE ASO_ORDER_FEEDBACK_T

前陣子顧問通知我們,我們EBS 11i上有一個9G的Table:ASO_ORDER_FEEDBACK_T, 雖然沒有相關模組在使用,但是也是會增長,所以建議停用且刪除資料。

先依文件ID 1432251.1檢查是否有被使用
(How To Determine If Trade Management Is Used Before Truncating ASO_ORDER_FEEDBACK_T)

SQL> select count(1) from ozf_funds_utilized_all_b;
SQL> select count(1) from ozf_funds_all_b;
SQL> select count(1) from ozf_act_budgets;

上面的結果回傳都是0,表示我們曾未執行過Funds Accrual Engine,也沒有使用Trade Management Budgets模組

接著到ERP去停用它,以免未來它又不斷地增長
需要用到Responsibility:Quoting Sales Manager


Quoting Sales Manager-> Quick Codes
尋找Type是ASO_ORDER_FEEDBACK_CRM_APPS,並且取消OZF的Enabled勾選,也可以直接刪除OZF,如下圖



接著刪除ASO.ASO_ORDER_FEEDBACK_T的資料,文件(ID 603427.1)提到要truncate四個table
truncate table ASO.ASO_ORDER_FEEDBACK_T REUSE STORAGE;
truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_I REUSE STORAGE;
truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_H REUSE STORAGE;
truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_T REUSE STORAGE;

由於我們的DB是11gR2,已經不建議用上面的方式來刪除AQ objects,所以出現了ora-24005的錯誤訊息
SQL> truncate table ASO.ASO_ORDER_FEEDBACK_T;
truncate table ASO.ASO_ORDER_FEEDBACK_T
                   *
ERROR at line 1:
ORA-24005: Inappropriate utilities used to perform DDL on AQ table
ASO.ASO_ORDER_FEEDBACK_T

改用DBMS_AQADM的Package來刪除ASO.ASO_ORDER_FEEDBACK_T,程式如下:
declare
  po dbms_aqadm.aq$_purge_options_t;
begin
  po.block := FALSE;
  dbms_aqadm.purge_queue_table_table(
      queue_table => 'ASO.ASO_ORDER_FEEDBACK_T',
       purge_condition => null,
       purge_options => po );
end ;
/

查詢一下dba_objects,發現不是只有ASO_ORDER_FEEDBACK_T有改變
SQL> select owner,
            object_name,
            to_char(last_ddl_time,'yyyy/mm/dd hh24:mi') last_ddl_time
       from dba_objects
       where last_ddl_time >= to_date('20140515','yyyymmdd')
         and object_name like '%ASO_ORDER_FEEDBACK%';

          OWNER      OBJECT_NAME                    LAST_DDL_TIME
---------- ------------------------------ --------------------------------
ASO        AQ$_ASO_ORDER_FEEDBACK_T_H     2014/05/15 16:37
ASO        AQ$_ASO_ORDER_FEEDBACK_T_I     2014/05/15 16:37
ASO        AQ$_ASO_ORDER_FEEDBACK_T_T     2014/05/15 16:37
ASO        ASO_ORDER_FEEDBACK_T                   2014/05/15 16:37

查詢ASO_ORDER_FEEDBACK_T的大小,發現只剩下0.13MB
SQL> select segment_name,segment_type,round(sum(bytes)/1024/1024,2) "MB" ,sum(blocks) "BLOCKS"
        from dba_segments
        where segment_name = 'ASO_ORDER_FEEDBACK_T'                                          
        group by  segment_name,segment_type ;

SEGMENT_NAME                   SEGMENT_TY         MB     BLOCKS
------------------------------ ---------- ---------- ----------
ASO_ORDER_FEEDBACK_T           TABLE             .13         16


我只有執行到這裡,ID 603427.1提到有四個步驟要做,如下:

Step 1 : Truncate the table
sqlplus "/as sysdba"
SQL> truncate table ASO.ASO_ORDER_FEEDBACK_T REUSE STORAGE;
SQL> truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_I REUSE STORAGE;
SQL> truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_H REUSE STORAGE;
SQL> truncate table ASO.AQ$_ASO_ORDER_FEEDBACK_T_T REUSE STORAGE;
SQL> COMMIT;


Step 2 : Grant execute rights on SYS.DBMS_AQADM and SYS.DBMS_AQ packages with Grant options to users APPS & ASO
grant execute on SYS.DBMS_AQADM to ASO WITH GRANT OPTION;
grant execute on SYS.DBMS_AQADM to APPS WITH GRANT OPTION;
grant execute on SYS.DBMS_AQ to ASO WITH GRANT OPTION;
grant execute on SYS.DBMS_AQ to APPS WITH GRANT OPTION;


Step 3:  Run asoqueue.sql script.
$ cd $ASO_TOP/patch/115/sql


Step 4: When previous steps are completed, then run :-
ALTER TABLE ASO.ASO_ORDER_FEEDBACK_T DEALLOCATE UNUSED;
ALTER TABLE ASO.AQ$_ASO_ORDER_FEEDBACK_T_I DEALLOCATE UNUSED;
ALTER TABLE ASO.AQ$_ASO_ORDER_FEEDBACK_T_H DEALLOCATE UNUSED;
ALTER TABLE ASO.AQ$_ASO_ORDER_FEEDBACK_T_T DEALLOCATE UNUSED;


EBS 11i 找出ar60run在執行哪一個Concurrent Request

因為在top中看見有一個ar60run資源使用最大,所以想了解是什麼程式在執行,
ar60run是Report的執行程式,如下PID:15733
CPU TTY  PID USERNAME PRI NI   SIZE    RES STATE    TIME %WCPU  %CPU COMMAND
 6   ? 15733 prodmgr  240 20   166M   127M run    142:28 97.61 97.44 ar60run
 1   ? 21562 oraprod  240 20  5350M  4888K run    205:05 94.74 94.57 oraclePROD
 3   ? 12657 oraprod  239 20  5355M  7128K run      4:44 72.11 71.98 oraclePROD

利用ps找出PID:15733程序的訊息
# ps -ef |grep 15733
test 15733 23609 252 09:05:50 ? 140:35 ar60run P_CONC_REQUEST_ID=11835973 P_BREAK_ID='1' P_RPT_UOM='2'

記錄下P_CONC_REQUEST_ID=11835973,到ERP內找出Request ID為11835973的Concurrent Request



Oracle 9i export某一個TABLE的資料,再import到11g

有一個在9i的tmp_ccc表格,想要移轉到11g,當然可以用DB_LINK將兩台DB連接後再insert資料過去。
但是我想先把tmp_ccc的資料備份出來,等有需要時再匯入11g。

在9i的OS下,執行exp匯出資料檔
$ exp test01/XXXXX file=/home/oraprod/exp_test.dmp buffer=65400 feedback=100 tables=tmp_ccc 

Export: Release 9.2.0.7.0 - Production on Wed May 14 16:14:30 2014

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
Export done in UTF8 character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...
. . exporting table                        TMP_CCC
..........
                                                         1018 rows exported
Export terminated successfully without warnings.


總共有1018筆資料匯出成功,接著我利用FTP的方式把資料檔(exp_test.dmp)傳到11g的DB上。

在11g的OS下,執行imp匯入資料檔,因為11g已有temp_ccc的表格,所以加上data_only參數只匯入資料。
$ imp test01/XXXXX file=/export/home/testora/exp_test.dmp  feedback=100 tables=tmp_ccc data_only=Y

Import: Release 11.2.0.4.0 - Production on Wed May 14 16:29:35 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export file created by EXPORT:V09.02.00 via conventional path
import done in UTF8 character set and AL16UTF16 NCHAR character set
. importing CUSADMIN's objects into CUSADMIN
. . importing table                      "TMP_CCC"
IMP-00058: ORACLE error 904 encountered
ORA-00904: "F": invalid identifier
Import terminated successfully with warnings.

結果出現ORA-00904的錯誤,比較兩方的表格之後,發現9i的tmp_ccc多了一個欄位「F」,是後來新增的。
所以在11g的DB下,也新增欄位如下:
SQL> alter table test01.tmp_ccc add f varchar(100);


回到11g的OS底上,重新執行imp匯入資料,這次就成功了。
$ imp test01/XXXXX file=/export/home/testora/exp_test.dmp buffer=65400 feedback=100 tables=tmp_ccc data_only=Y

Import: Release 11.2.0.4.0 - Production on Wed May 14 16:52:13 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export file created by EXPORT:V09.02.00 via conventional path
import done in UTF8 character set and AL16UTF16 NCHAR character set
. importing CUSADMIN's objects into CUSADMIN
. . importing table                      "TMP_CCC"
..........
                                                         1018 rows imported
Import terminated successfully without warnings.

ORACLE 11g 資料壓縮測試

先建立一個沒有啟用壓縮功能的測試表格
SQL> create table test01
  2    ( a varchar2(100),
  3      b varchar2(20) );
 

確認壓縮功能沒有啟用
SQL> SELECT table_name --資料表名稱
  2        ,compression --是否啟用壓縮
  3        ,compress_for --壓縮類型
  4    FROM dba_tables
  5    where table_name='TEST01';

TABLE_NAME      COMPRESSION      COMPRESS_FOR
--------------- ---------------- ------------------------
TEST01          DISABLED


寫入資料
SQL> insert into test01 select object_name,object_id from dba_objects;
74838 rows created.

SQL> insert into test01 select object_name,object_id from dba_objects;
74838 rows created.

SQL> commit;
Commit complete.


查詢test01的大小
SQL> select segment_name,bytes,blocks
  2      from dba_segments
  3      where segment_name='TEST01';

SEGMENT_NAME              BYTES     BLOCKS
-------------------- ---------- ----------
TEST01                  6291456        768


將test01資料刪除
SQL> truncate table test01;
Table truncated.


啟用test01的壓縮功能,並指定壓縮類型為OLTP
SQL> ALTER TABLE test01 COMPRESS FOR OLTP;
Table altered.


也可以在建立表格時指定,語法如下:
create table my_compressed_table
  ( col1 number(20), col2 varchar2(300), ... ) compress for all operations ;


確認縮壓功能有啟用且類型為OLTP
SQL> SELECT table_name
  2        ,compression
  3        ,compress_for
  4    FROM dba_tables
  5    where table_name='TEST01';
 
TABLE_NAME      COMPRESSION      COMPRESS_FOR
--------------- ---------------- ------------------------
TEST01          ENABLED          OLTP


寫入資料到test01
SQL> insert into test01 select object_name,object_id from dba_objects;
74838 rows created.

SQL> insert into test01 select object_name,object_id from dba_objects;
74838 rows created.

SQL> commit;
Commit complete.


重新查詢資料大小,發現容量比未壓縮小
SQL> select segment_name,bytes,blocks
  2          from dba_segments
  3         where segment_name='TEST01';

SEGMENT_NAME              BYTES     BLOCKS
-------------------- ---------- ----------
TEST01                  5242880        640

VirutalBox 4.3.8 Log的位置(Win7)

因為Guest OS一直有問題,想知道是不是VirutalBox的問題,所以想查看Log,其位置如下:

Windows 7:
%HOMEDRIVE%%HOMEPATH%\.VirtualBox\
例如:C:\Users\JOHN\.VirtualBox\VBoxSVC.log

Oralce 11g 在啟動資料庫時,出現ORA-01113: file 3 needs media recovery

今天嘗試在UNDO Datafile刪除之後(只是把檔案更名而已)的還原方式,
試了幾種不用隱藏的參數*._offline_rollback_segments的方法都失敗,
在恢後UNDO Datafile之後開啟資料庫,卻出現了needs media recovery的訊息。

SQL> startup
ORACLE instance started.

Total System Global Area  456146944 bytes
Fixed Size    1344840 bytes
Variable Size  394267320 bytes
Database Buffers   54525952 bytes
Redo Buffers    6008832 bytes
Database mounted.
ORA-01113: file 3 needs media recovery
ORA-01110: data file 3: '/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf'

試著RECOVER資料庫
SQL> recover database;
ORA-00279: change 9613767 generated at 05/11/2014 20:42:31 needed for thread 1
ORA-00289: suggestion : /backup/archive/orcl_1_428_701609923.arc
ORA-00280: change 9613767 for thread 1 is in sequence #428

我是輸入AUTO
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO

ORA-00279: change 9638206 generated at 05/11/2014 22:17:58 needed for thread 1
ORA-00289: suggestion : /backup/archive/orcl_1_429_701609923.arc
ORA-00280: change 9638206 for thread 1 is in sequence #429
ORA-00279: change 9658236 generated at 05/11/2014 22:20:19 needed for thread 1
(…略)

Log applied.
Media recovery complete.

完成RECOVER之後,將資料庫啟動到OPEN的模式
SQL> alter database open;

Database altered.

到此就完成了。

Oracle 11g--測試temporary datafile被刪除

找出TEMPORARY的Datafile位置
select a.file#,a.ts#,a.status,b.name,a.name
    from v$tempfile a,
              v$tablespace b
    where a.ts#=b.ts#
    and b.name =  
        (select property_value
             from database_properties
             where property_name='DEFAULT_TEMP_TABLESPACE') ;

關閉資料庫
SQL> shutdown abort ;
ORACLE instance shut down.

到作業系統底下將datafile更名
$ mv temp01.dbf temp01.dbf.bk

重新開啟資料庫
SQL> startup
ORACLE instance started.

Total System Global Area  456146944 bytes
Fixed Size    1344840 bytes
Variable Size  394267320 bytes
Database Buffers   54525952 bytes
Redo Buffers    6008832 bytes
Database mounted.
Database opened.
SQL>

發現可以正常啟動資料庫,檢查一下實際的Datafile,Oracle新增了一個2G的temp01.dbf
$ ls -l temp*
-rw-rw---- 1 oracle oracle   20979712 May 11 19:48 temp01.dbf
-rw-r----- 1 oracle oracle  165683200 May 11 19:34 temp01.dbf.bk

先找出11g alert log的位置
SQL>select value from v$diag_info where name ='Diag Trace';

VALUES
-----------------------------------------------------------
/home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace


檢查alert log的訊息
$ more /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
可以發現Oracle自動重建了tempfile
Re-creating tempfile /home/oracle/app/oracle/oradata/orcl/temp01.dbf

Solaris 10 設定.profile後出現-sh: EDITOR=vi: is not an identifier

因為每次要執行crontab -e之前都要先export EDITOR=vi,所以想把變數EDITOR設定到.profile內,
下面是我修改後.profile的內容:
PATH=$PATH:/usr/X/bin:/usr/X11/bin
export PATH
export EDITOR=/usr/bin/vi
bash

但是重新登入後卻出現了-sh: EDITOR=vi: is not an identifier的錯誤訊息,
所以重新修改.profile,將export EDITOR=/usr/bin/vi分為兩行指令就正常了,內容如下:
PATH=$PATH:/usr/X/bin:/usr/X11/bin
export PATH
EDITOR=/usr/bin/vi
export EDITOR
bash

Oracle SQL找出上/下一筆某個欄位值來計算

有時候希望以上/下一筆的某個欄位值來計算,例如想知道今天與昨天交易量的差異數時,
通常是以編寫PL/SQL來達成目的。
但是今天在網路上看到原來有lead()和lag()兩個function可以直接以SQL完成。

例如:

SQL> select * from tmp_ccc

a      b    
------ -----
1      0  
2      10
3      30
4      40

lag() function:找出上一筆的資料
SQL> select a, lag(b) over (order by b) test from test_ccc;

a      test    
------ -----
1        
2      0
3      10
4      30

lead() function:找出下一筆資料
SQL> select a, lead(b) over (order by b) test from test_ccc;

a      test    
------ -----
1      10  
2      30
3      40
4    

用IDM下載百度的檔案,解決斷線、速度0kb、檔案不完整,可以續傳、換網址下載

我用瀏覽器下載百度的檔案時,發現常常斷線、速度0kb、或是下載完的檔案並非完整。
後來下載迅雷7來使用,有時候還蠻快,下載成功的檔案也都是完整,
但是還是常常會有速度0kb,中斷太多次而導致失敗等問題,因為我不是迅雷的VIP會員,
所以不確定VIP是否也有這樣的問題。

最後在網上有許多人提到用IDM(Internet Download Manager )來下載,所以我也到官網下載試用,
發現上述這些問題都解決了,不僅支援續傳,還可以用不同的下載地址來續傳未完成的檔案,真是太厲害了。
新版IDM有支援win 8.1,正好符合我筆電的環境。

官網:http://www.internetdownloadmanager.com/

IDM的畫面


在網路上有人提到如果用百度下載太慢時,可以修改url的hostname來增加速度,
雖然我用IDM還沒有發生這樣的問題,但是還是來實驗一下。

首先找一個百度的檔案來下載,並將下載任務暫停,選擇內容。

修改網址hostname的部份,例如把nj.baidupcs.com改為qd.baidupcs.com按確定。
下面是一些網路上分享的百度下載的hostname,但是修改hostname不一定會加快下載速度,
這部份要自己測試看看。
nj.baidupcs.com
bj.baidupcs.com
qd.baidupcs.com
cdn.baidupcs.com
qd.cache.baidupcs.com
nj.cache.baidupcs.com
d.pcs.baidu.com
c.pcs.baidu.com
bcscdn.baidu.com


IDM會開始取得新網址下載的資訊,並開始續傳的作業,不用重頭下載。
所以如果有遇到斷線或0kb的問題,也許用此方法就可以繼續了。

修改前下載到14%就中斷

修改網址後會從14%開始續傳