Oracle

如果EXT4檔案系統上的ORACLE資料檔案被誤刪除了，那麼一般可以考慮下面2種恢複方式：使用testdisk工具從檔案系統角度恢複資料檔案使用prmscan工具從oracle 資料區塊角度恢複資料檔案這裡我們介紹使用testdisk的恢複ext4上資料檔案的步驟：刪除users資料檔案 [oracle@dbdao01 ~]$ df

出現Oracle 11g 使用者名稱密碼到期問題，處理方式如下：1：先登陸控制台進行驗證，weblogic內建的JDBC測試，可以驗證資料庫連通性。同時應用日誌應該會出現ORA-28002的密碼到期的錯誤提示。2：也可以登陸資料庫，使用原始使用者進行串連嘗試conn username/MIMA . 也會出現ORA-28002的密碼到期提示。具體操作如下：Oracle 

公司的一台oracle資料庫在啟動時候報錯ORA-27102： out of memory ，具體如下：現象: alter system set sga_max_size=12884901888 scope=spfile      ---(12G)出現: SQL >startup forceORA-27102: out of memoryLinux-x86_64 Error: 28: No space left on

使用PXE刷XD需要安裝服務binddhcpsystem-config-netboottftp-serverdhcp配置[root@oracleplus ~]# more /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 8)[root@oracleplus ~]# more /etc/dhcpd.confsubnet 192.168.30.0 netmask 255.255.255.0

在12c pdb環境中如果root pdb的undo檔案異常，資料庫該如何恢複呢？這篇文章類比undo丟失的情況下進行恢複類比環境三個會話，其中第一個會話對pdb1中的表進行操作，並且有事務未提交,第二個會話對pdb2進行操作，也未提交事務；第三個會話直接abort庫，類比突然庫異常，然後刪除root pdb下面的undo檔案--會話1[oracle@ora1221 oradata]$ sqlplus  / as sysdba SQL*Plus: Release 12.2.0

接到同事的電話，某省的一個用於監控的siteview資料庫啟動不了了，登入後檢查alertlog發現：Completed first pass scan 9868 redo blocks read, 655 data blocks need recoveryThu Apr 19 16:52:42 2007Started recovery at Thread 1: logseq 700, block 194931, scn 0.0Recovery of Online Redo

營運DBA反映資料庫儲存故障，導致redo undo兩個資料表空間資料檔案丟失，資料庫無法open啟動某集團的ebs系統因磁碟空間不足把redo和undo存放到raid 0之上，而且該庫無任何備份。最終悲劇發生了,raid 0異常導致redo undo全部丟失,資料庫無法正常啟動(我接手之時資料庫已經resetlogs過,但是未成功)1.Oracle報錯ORA-00604 ORA-00376Sun Jul 27 11:31:27 2014SMON: enabling cache

營運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='

記錄一次當前redo丟失的情況下ORACLE 12C CDB資料庫恢複的情況,ORACLE 12C redo異常恢複測試—部分pdb未正常open為了驗證當前redo丟失的情況下ORACLE 12C CDB資料庫恢複的情況,做了一個小實驗，三個會話，分別操作為在root pdb中執行一個delete 不提交；另外一個會話在user pdb中delete記錄不提交；最後一個會話中直接abort資料庫，然後進行資料庫恢複，驗證資料庫是否可以都正常open(所有pdb)會話1(root

最近有不少朋友諮詢12.1.0.2及其以後的版本使用oradebug去修改scn失敗,這裡做了一個測試正常情況下確實無法修改(oradebug poke報 ORA-32519 或者 ORA-32521) ,這裡進行了一系列修改測試最後修改成功.資料庫版本SQL> select * from v$version; BANNER             &

SKIP_UNUSABLE_INDEXES的使用與索引失效是相關的,該參數10g開始引入,11g預設為TRUE.當為TRUE時候,如果資料庫中存在usable狀態的索引,則會自動忽略該索引產生新的執行計畫(不走該索引,也不提示該索引的異常);當為False時候,則會報錯.我所營運的資料庫在一些關鍵系統中,會將此參數設成False,讓系統及時發現索引的異常以便及時去介入修複.環境各有所異,設定值也可依據實際情況設定.如果sql使用了hint或者涉及到唯一索引的對應DML,該參數會失效.該參數的一些

該參數與Cardinality Feedback特性有關,最佳化器可以估算基數不正確的原因有很多，如缺少的統計資訊，不準確的統計資料，或複雜的謂詞,基數統計反饋有助於最佳化器產生更合理的執行計畫.對於此特性我不作科普了,比較詳細的資料可以參考以下文檔:1.Tuning-by-Cardinality-Feedback.pdf2.Statistics (Cardinality) Feedback – Frequently Asked Questions (文檔 ID 1344937.1)

通過下面的語句查到復原的事務：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

客戶回函系統經常報會話逾時,導致應用測試無法正常進行,經檢查alert日誌發現Fatal NI connect error 12170.   VERSION INFORMATION:        TNS for HPUX: Version 11.2.0.4.0 - Production        Oracle Bequeath

資料庫版本oracle -> 11g @xifenfei:/home/oracle$sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 30 10:28:30 2014 Copyright (c) 1982, 2013, Oracle.  All rights reserved.  Connected to:Oracle Database 11g

資料庫版本  代碼如下複製代碼 SQL> select * from v$version; BANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionPL/SQL Release 11.2.0.4.0

朋友資料庫啟動遭遇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

在資料庫的恢複過程中遇到ORA-600 4000錯誤挺多的，但是在oracle 8i(8.1.7)中遇到此類問題，還是第一次，做個記憶，供參考：資料庫故障起因：因為儲存異常，導致當前redo損壞，並_allow_resetlogs_corruption參數嘗試開啟資料庫Media Recovery Log kcrrga: Warning.  Log sequence in archive filename wrappedto fix length as indicated by %S

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

資料庫不能啟動(或者啟動後馬上crash),alert日誌報錯ORA-00600[17182],ORA-00600[25027],ORA-00600[kghfrempty:ds]等錯誤Tue Jul 08 23:36:06 2014 alter database openBeginning crash recovery of 1 threads  parallel recovery started with 32 processes Started redo scan