數據庫管理員

今天是2014-03-26，因分析deadlock耽誤了寫RAC的東西，今天再來寫篇RAC中表決磁碟的管理日誌。特此記錄一下。 表決磁碟（votedisk）是為因網路導致腦裂的情況而建立的。表決磁碟在11G儲存在ASM中，且如果放入ASM將有幾點要求。 第一：表決磁碟檔案必須全部放入ASM中； 第二：表決磁碟存在asm中的個數不能刪除和添加，而是通過asm的normal，high、external冗餘層級決定的。 如：在normal中必須有3個故障組存在3

啟動時應用重做日誌，關閉時取消重做日誌：8.1Starting Up and Shutting Down a Physical Standby DatabaseThis section describes the SQL*Plus statements used to start up and shut down a physical standby database.8.1.1Starting Up a Physical Standby Database8.1.1

打算做一個Oracle索引的專題技術筆記，因為今天幫我一個深圳的朋友做過rman的測試，在 恢複我未經處理資料的時候，發現存在ORA-XXXXX錯誤，測試結果如下：   run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; allocate channel ch4 type

環境os $ cat /etc/RedHat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) $ uname -a Linux yozhan1.Oracle.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux db 2節點rac  

今天是2014-04-01，忙碌了一天終於有時間寫點東西了。前段時間寫了RAc中ocr存在備份的情況下如何恢複，今天寫一下在沒有備份情況下如何去重建ocr和olr呢？最大的悲劇莫過於資料庫壞了備份沒了。讓我想起了前幾年流行的一句話：“最大的悲劇是人活著，錢沒了”。總之備份重於一切。情景介紹：在11G中ocr的asm磁碟組被使用者不小心刪了且所有備份都誤刪，olr呢也損壞了。至此悲劇重演。恢複過程：（其實就是使用root.sh重建ocr的過程，重建之後可能需要重新註冊相關資

1、Oracle同名複製-131伺服器上建立庫PROD1，然後將其遷移至137伺服器，庫名仍為PROD1 1.1 dbca-131 PROD1 sys/oracle system/oracle uncheck all components no EM no Flashback no Archiving ORA-00845 when using dbca to create a

環境：VBOXOracle ENTERPRISE LINUX 5.8_X86_64ORACLE DATABASE 10.2.0.1.0ORACLE CLUSTERWARE 10.2.0.1.0在重新搭建一套RAC環境的時候，因為不想多建新的OCR/VOTING DISK共用磁碟，就打算使用上一套RAC環境中用過的共用磁碟。也考慮過，重用這些共用磁碟，可能會出一些狀況，打算嘗試一下，看看在哪些步驟上會出問題。推薦閱讀：裸裝置建立ASM磁碟 Oracle通過軟串連裸裝置建庫

前言在學習Oracle的過程中，除了要安裝Oracle資料庫軟體以外，我們經常要在沒有Oracle資料庫環境的主機上安裝Oracle client，以便通過網路訪問Oracle伺服器。現在將在RHEL 5.5 x86 系統中安裝Oracle Instant Client具體步驟示範如下：安裝環境：在本文中，RHEL 5.5 x86是安裝在虛擬機器中，用secureCRT進行串連。一

ORA-03113:通訊通道的檔案結尾 進程ID4781 查看alter.log 發現提示聯機記錄檔有問題 網上的方法看不是很懂，看到有很多錯誤 ora-16038:日誌無法歸檔 ora-00312 ORA-19809: limit exceeded for recovery files

1、當前資料庫環境： 雙節點Oracle linux 5.4 RAC Grid software  11.2.0.4 Oracle software 11.2.0.4 OPatch Version  11.2.0.3.4 2、OPatch下載 下載11.2.0.4.1 Patch:17478514 p17478514_112040_Linux-x86-64.zip 根據該psu readme ：&

跑預存程序，裡面有張暫存資料表。跑完後打算刪除暫存資料表報ORA-14452：An attempt was made to create, alter or drop an index on temporary table which is already in use解決方案：實際上要麼就是等，等到資源釋放。要麼就是刪除sid。1、查詢object_idselect object_id from dba_objects where object_name=UPPER('TBL_1');----

隨著版本不斷地提升，RMAN作為標準備份工具的作用地位是不斷的被增強。從過去傳統的備份還原工具，到現在新環境遷移、DG搭建，我們都可以看到RMAN工具增強身影。本篇就以RMAN為工具，利用RMAN備份在新主機上搭建服務名相同的資料庫。由於環境所限，筆者採用的方法是：先進行備份擷取，之後刪除掉原資料庫，最後使用備份重新搭建（包括參數、控制檔案和資料檔案恢複）。推薦閱讀：RMAN 配置歸檔日誌刪除策略 Oracle基礎教程之通過RMAN複製資料庫 RMAN備份策略制定參考內容 RMAN備份學習筆記

今天碰到一個比較奇怪的問題:在用戶端上使用sqlplus用普通使用者可以登入，但是system以及sys使用者均無法登入，提示ORA-12154: TNS: 無法解析指定的串連標識符[@more@]SQL> conn system@webdata輸入口令:ERROR:ORA-12154: TNS: 無法解析指定的串連標識符SQL> conn

今天在測試資料庫發現alert出現警告錯誤Memory Notification: Library Cache Object loaded into SGAHeap size 2919K exceeds notification threshold (2048K)KGL object name :select     service_name, uio_waits, uio_time, con_waits, con_time,    

在11.2後的版本中crs被稱為gi，通過crsctl stop cluster來關閉整個執行個體的資源非常方便，但是對於資料庫執行個體需要單獨關閉,stop cluster對於執行個體直接以非正常的方式結束，環境是基於12C的。正確的順序:先關閉資料庫[Oracle@rac1 ~]$ srvctl stop database -db ttalert.log顯示是通過immediate方式關閉.Sat Apr 19 05:12:19 2014 Shutting down

1.1.1. ORA-19502,ORA-27072日期：2014-05-12 00:12環境：測試機【錯誤號碼】$ oerr ora 1950219502, 00000, "write error on file\"%s\", block number %s (block size=%s)"// *Cause: write error on output file// *Action: check the file$ oerr ora 2707227072, 00000, "File I/O

Oracle 10g以後，在目錄結構和檔案管理方面推出兩個特性OFA和OMF。OFA（Oracle Flexiable Architecture）是進行目錄結構約束規範的特性。診斷檔案diag、日誌、資料檔案等目錄結構分布都是由OFA進行固定下來。OMF（Oracle Managed

用用戶端連入Oracle伺服器的主要方法。從組件相關方角度看，Oracle Net串連過程涉及到很多的技術和過程，例如用戶端串連方式、連接字串、監聽器行為和資料庫執行個體。 一般我們都是藉助Oracle Client（非JDBC）的OCI介面方式進行Oracle串連，配置本地串連名local name。一旦串連過程出現錯誤，我們的診斷策略也是從外到內，從用戶端到伺服器逐步診斷。不同使用者下使用tnsping+用戶端服務名，結果不同 Oracle中tnsping命令解析

系統內容：作業系統：RedHat EL55Oracle ： Oracle 11.2.0.1.0叢集軟體：Oracle GI 11.2.0.1.0錯誤現象：[oracle@node1 ~]$ srvctl add database -d stddb -o /u01/app/oracle/product/11.2.0/db_1/ -n cuug[oracle@node1 ~]$ srvctl add instance -d stddb -i stddb1 -n node1[oracle@node1

10.2.0.5 on windows 64 bit 現象：從一個 server A拷貝backupset 至另一個server B。在server B上恢複。首先使用‘catalog start with ’編錄backupset . 在恢複資料庫的時候出現： RMAN> restore database force;Starting restore at 31-MAY-14 using channel ORA_DISK_1