Oracle

客戶資料庫異常(ORA-600 kcbz_check_objd_typ_1),讓我們遠程給分析處理ORA-600 kcbz_check_objd_typ_1異常Mon Aug  8 12:19:28 2016Completed: ALTER DATABASE OPENMon Aug  8 12:19:29 2016db_recovery_file_dest_size of 20480 MB is 0.00% used. This is auser-specified

營運DBA反映生產Oracle資料庫儲存掉線Oracle資料庫故障無法啟動報錯:ORA-00600[2131] ORA-07445[kdxlin]等錯誤1.啟動報ORA-00600[2131]錯誤Fri Nov 06 14:50:59 2015ALTER DATABASE   MOUNTThis instance was first to mountFri Nov 06 14:50:59 2015ALTER SYSTEM SET local_listener='

通過下面的語句查到復原的事務：select * from v$fast_start_transactions;或者select * from x$ktuxe where KTUXECFL='DEAD' AND KTUXESTA!='INACTIVE'根據上面的語句，我們可以查到事務的undo的segment id（USN或者KTUXEUSN），undo的slot（SLT或者KTUXESLT），和undo的sequence（SEQ或者KTUXESQN）。根據USN，我們可以查到undo

千呼萬喚oracle dul 11終於發布了,迫不及待的下載來測試,現在版本號碼為dul 11.2.0.0.1,目前只發布了for linux,其他版本估計要等等.期待該版本有引進新功能oracle dul 11發布dul-11.2oracle-dul-11dul 11 測試恢複oracle 12c版本[root@ora1221 dul11]# ./dul Data UnLoader: 11.2.0.0.1 - Internal Only - on Mon Jun 13 00:04:5

前面我們已經講解過11.2 RAC的啟動過程，可以注意到，RAC的根守護進程是/etc/init.d/init.ohasd，那麼不同版本的Linux中/etc/init.d/init.ohasd是如何啟動的呢？注意：12.1的非Flex Cluster啟動過程跟11.2 RAC一致。但是從12.2beta版 RAC的測試結果來看，從12.2開始OUI安裝很可能只有Flex Cluster了，沒有了11.2的那種普通RAC了。.Linux4和Linux5中，在完成核內引導(核心被載入記憶體並運行,

客戶將asm的執行個體配置錯了主機，asm1運行在節點2，asm2運行在節點1，在進行de-config和re-config之後，asm的alertlog大量報錯：SYMPTOMS:NOTE: Attempting voting file refresh on diskgroup GRIDNOTE: Voting file relocation is required in diskgroup GRIDNOTE: Attempting voting file relocation on

客戶有個環境是10g的RAC，由於一次偶爾的需求，需要將一個11g的資料庫臨時在上面啟動，當我們mount了11g的軟體卷和datafile 卷之後，11g的資料庫能正常啟動，但是當11g的資料庫shutdown時，導致了10g的crsd進程重啟。在10g的crsd的log中，可以看到：2011-10-16 11:35:35.827: [ OCRAPI][267]procr_open_key: Invalid keyname [CRS.CUR.]. Component too big.2011-

將10.2.0.5的一個大表匯入到12.1.0.2的時候，匯出參數是：[oracle10g@testdb tmp]$ cat expdp.paruserid='/ as sysdba'DIRECTORY=DUMPDIRdumpfile=mytable_%U.dmptables=schema.mytablelogfile=mytable.logjob_name=mytableparallel=8filesize=100M匯入參數是：userid='/ as

當字串為空白時，在where 使用 is null來判斷。例子：create table test(   stuno number(10) primary key,   stuname varchar2(50))insert into test(stuno) values(10)insert into test(stuno,stuname) values(11,' ')select * from test where stuname is

這周折騰了2天的時間幫客戶成功恢複了一套近1.4TB的10.2.0.5 RAC(ASM). 該庫在3月4號直接crash了。大家可以看到，該庫在開始報錯讀取redo,controlfile報錯,本質原因是DISKGROUP dismount了,資訊如下：Tue Mar 04 18:09:59 CST 2014Errors in file /home/oraprod/10.2.0/db/admin/xxxx/bdump/xxxx_lgwr_15943.trc:ORA-00345: redo

這是某個網友的資料庫，11g ASM環境. 其中ASM中繼資料出現損壞，導致DiskGroup無法mount。不過比較萬幸的儲存有鏡像。即使是這樣，據說儲存工程師恢複也花了1天多，對於我們的業務系統來講，這是不可接受的。我這裡將該資料庫case的資訊貼出來，供大家參考！（備忘：我們提供完善的資料庫各種解決方案，詳情請看:雲和恩墨)WARNING: cache read  a corrupt block: group=3(DATAVG) dsk=27 blk=1 disk=27

主要問題是：oracle用戶端軟體的字元編碼與伺服器端的字元編碼不一致造成的。oracle服務端字元編碼為： ZHS16GBKoracle用戶端字元編碼為:WE8ISO8859P1解決辦法有三種：(1)修改用戶端註冊表： 找到Oracle安裝註冊項下的NLS_LANG，將其值改為"SIMPLIFIED CHINESE_CHINA.ZHS16GBK(2)通過調用_putenv函數,在程式中用代碼設定:using

--查看最耗磁碟讀寫率的磁碟語句 select * from (select v.sql_id, v.child_number, v.sql_text, v.elapsed_time, v.cpu_time, v.disk_reads, rank() over(order by v.disk_reads desc) elapsed_rank from v$sql v) a where

有網友在QQ上找我,說Oracle 7.3的資料庫,因為redo異常諮詢我是否可以恢複  檢查資料庫得到以下資訊  代碼如下 複製代碼 SVRMGR> select * from v$version; BANNER -----------------------------------------

簡單CASE運算式,使用運算式確定傳回值.文法:  代碼如下複製代碼 CASE search_expressionWHEN expression1 THEN result1WHEN expression2 THEN result2...WHEN expressionN THEN resultNELSE default_result 搜尋CASE運算式,使用條件確定傳回值.文法:  代碼如下複製代碼 CASEWHEN condition1 THEN

1、下載Oracle 11g R2 for Windows的版本下載地址：

接到網友支援人員請求,win 2003 ntfs格式檔案系統,Oracle 8.1.7版本,主機重啟後,資料庫無法正常啟動,offline datafile 15,資料庫open成功,但是datafile 無法正常online,報錯為:ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file,請求協助處理SQL> recover datafile 'D:/ORACLE/ORADATA/ORCL/ZSF_DATA.

資料庫最初故障Thu Sep 25 09:27:26 2014MMON started with pid=15, OS id=1968 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...starting up 1 shared server(s) ...ORACLE_BASE from environment = F:＼oracleThu Sep 25 09:27:2

朋友資料庫啟動遭遇ORA-00600[2663]Mon Sep 22 19:24:20 2014Thread 1 advanced to log sequence 17 (thread open)Thread 1 opened at log sequence 17  Current log# 17 seq# 17 mem# 0: /u02/orayali2/redo17.logSuccessful open of redo thread 1MTTR advisory is

recover database 報ORA-600 3020  代碼如下複製代碼 Recovery of Online Redo Log: Thread 1 Group 2 Seq 5729 Reading mem 0  Mem# 0: E:＼ORACLE＼ORADATA＼YYGDB＼REDO02.LOGTue Aug 19 19:37:29 2014Errors in file