Oracle

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

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

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

客戶將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

在dataguard上，使用rman串連catalog資料庫進行備份。備份的時候，rman的日誌報錯如下：Starting backup at 2014/04/23-10:02:02archived log /aabb/qb/mobprd/log/fra/mobprd/archivelog/2014_04_23/o1_mf_1_201410_9ofpggpg_.arc not found or out of sync with catalogskipping inaccessible file

客戶有個環境是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-

某個朋友公司的客戶，友情幫忙分析的。客戶使用的是oracle 12c(12.1.0.1),應用通過jdbc訪問發現時快時慢。但是通過sqlplus訪問發現一切正常。開始以為是防火牆問題，檢查發現防火牆什麼的都是禁用掉了，甚至我還修改了selinux=disable，發現問題依舊。由於之前處理過幾個類似的case，都是jdbc版本的問題，因此開始我讓他們換幾個jdbc版本測試下，發現問題依舊。類似如下結果：[oracle@12c_single ~]$

故障現象:OEM（Oracle Enterprise Manager）是Oracle提供的一個強大的資料庫管理工具，通過WEB圖形方式，進行資料庫的日常狀態檢查，調優等資料庫管理工作，極大減輕了DBA的工作量。那麼，如何才能啟動OEM管理工具？解決方案:啟動OEM的步驟，整理如下：1. 啟動監聽，如果監聽不存在，首先要建立監聽  代碼如下複製代碼 [oracle@localhost]$ cd

如在ms sqlserver 用此語句：  代碼如下複製代碼 select top 2 * from test01 Oracle的語句:  代碼如下複製代碼 select * from (select rownum r ,* from test) ttwhere tt.r > 50 and tt.r <= 100; (最好用PLSQL遊標來解決)DB2中：  代碼如下複製代碼 select * from payment

AMERICAN_AMERICA.WE8ISO8859P1,這個字元編碼是西歐字元編碼,對應於.Net的就是iso-8859-1字元編碼,所以只需要改到系統的預設字元編碼就行了.解決方案：(1) 伺服器端重新安裝ORACLE　　在重新安裝ORACLE 時選擇與原卸出資料一致的字元集(本例為US7ASCII)。　　載入原卸出的資料。　　這種情況僅僅使用於空庫和具有同一種字元集的資料。(2)寫一個函數:  代碼如下複製代碼  /**//// <summary>

報錯1：ORA-01756: quoted string not properly terminated字元集編碼不一致造成的中文內容無法插入查詢當前資料庫的字元編碼設定：SQL> select * from v$nls_parameters T WHERE t.PARAMETER = ‘NLS_LANGUAGE’ or t.PARAMETER = ‘NLS_CHARACTERSET’;或者SQL> select

racle其實也差不多，只不過oracle本身設計的安全性和穩定性都十分好。所以相應的設定檔也要多些。1、先將原oracle的安裝目錄和data目錄都做個備份。然後安裝oracle，安裝路徑要和原來的一樣。安裝時選擇'只安裝軟體'即可，不用選擇安裝資料庫。例如：安裝在E:oracleproduct10.2.0目錄，會發現在該目錄只有一個db_1目錄。2、再將db_1NETWORKADMIN目錄下的tnsnames.ora、sqlnet.ora、listener.ora檔案拷到相應的目錄中。3、配

　Sequence是資料庫系統按照一定規則自動增加的數字序列。這個序列一般作為代理主鍵（因為不會重複），沒有其他任何意義。　　Sequence是資料庫系統的特性，有的資料庫有Sequence，有的沒有。比如Oracle、DB2、PostgreSQL資料庫有Sequence，MySQL、SQL

使用以下語句：O_CHAR(pubtime,'yyyymmdd HH:mm:ss')，例如：  代碼如下複製代碼 select id,TO_CHAR(pubtime,'yyyymmdd HH:mm:ss'),content from bj_ref.gz_twinfo_ref  where user_id=2603 and TO_CHAR(pubtime,'yyyymmdd HH:mm:ss')>='20140704 20:58:42'  and

十進位轉換二進位  代碼如下複製代碼 CREATE OR REPLACE FUNCTION NUMBER_TO_BIT(V_NUM NUMBER)  RETURN VARCHAR IS V_RTN VARCHAR(8);--注意返回列長度   V_N1  NUMBER;   V_N2  NUMBER; BEGINV_N1 := V_NUM;     LOOP

通過odu挖rman備份前和備份後的資料檔案,得知rman backup備份的過程,對絕大多數truncate的表的未經處理資料未正常備份(為什麼是絕大多數,我無法給出解釋),這裡也可以看出rman backup並非是真正意義上的完全物理上複製(和rman copy還是有區別,copy不能完全被取代)建立類比環境  代碼如下複製代碼 SQL> select * from v$version;    BANNER --------------------

資料庫版本  代碼如下複製代碼 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

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