Oracle Active Data Guard調整案例[2]客戶的Oracle 11gR2 Active Data Guard環境,主要資料庫的standby_file_management=AUTO,備用資料庫的standby_file_management=MANUAL,導致在主要資料庫為資料表空間添加的資料檔案操作沒有同步到備用資料庫,在$ORACLE_HOME/dbs目錄下也沒有建立類似UNNAMED00003的檔案,備用資料庫有如下的警示日誌:Tue Sep 02 17:37:36
Oracle 11gR2 Active Data Guard調整案例[1]客戶的環境是Oracle RAC Database 11.2.0.3 for Linux x86_64bit+Oracle Database 11.2.0.3 for Linux x86_64bit(ADG備庫),RAC使用的是ASM,備庫使用的是檔案系統。客戶在RAC主庫為SYSTEM資料表空間添加了一個資料檔案,由於指令碼有問題該資料檔案被放在了node 1的本地檔案系統上,導致node
Oracle 11gR2 Database和Active Data Guard遷移案例客戶一套核心系統由一台Oracle Database 11.2.0.3.4單機和一台Active Data Guard組成,分別運行在兩台PC伺服器上,Oracle Linux 5.8 x86_64bit作業系統,兩台伺服器都未接存放裝置;由於原有裝置老舊等原因,現在要將這套Oracle資料庫系統(主庫和ADG庫)遷移到新採購的兩台伺服器上,不跨版本,也不跨平台。為了最小化停機時間,我們先用目前最新的RMAN
alter system archive log current / all / switch logfilealter system switch logfile ; 對單一實例資料庫或RAC中的當前執行個體執行強制日誌切換,歸檔當前重做日誌,Oracle9i之前如果自動歸檔沒有開啟,就不歸檔當前重做記錄檔 。alter system archive log current ; 對資料庫中的所有執行個體執行日誌切換(只歸檔當前日誌)。alter system archive log all ;
MySQL 5.1同步到5.5卡庫問題一則今天在MySQL 5.1同步到5.5時遇到一則卡庫問題,在從庫上show slave status \G,報錯如下:Error 'BIGINT UNSIGNED value is out of range in '(group.mg_group_var.grp_status_cnt + -(38))'' on query. Default database: 'group'. Query: 'update mg_group_var set
Redo丟失的4種情況及處理方法一.說明:1.以下所說的當前日誌指日誌狀態為CURRENT,ACTIVE,非當前日誌指日誌狀態為INACTIVE2.不用考慮歸檔和非歸檔模式,2種模式下的Redo丟失情況一樣。二.丟失Redo的4種情況:第一種情況:非當前日誌,正常關閉。第二種情況:非當前日誌,非正常關閉。第三種情況:當前日誌,正常關閉。第四種情況:當前日誌,非正常關閉。三.處理方法:第一、二種情況的處理方法一樣,直接把記錄檔clear即可。SQL> alter database
為MySQL選擇合適的備份方式MySQL資料庫的備份是極其重要的事情。如果沒有備份,遇到下列情況就會抓狂:UPDATE or DELETE whitout where…table was DROPPed accidentally…INNODB was corrupt…entire datacenter loses
Oracle-SQL_TRACE使用,oraclesqltraceselect sid,serial# from v$session where schemaname='SCOTT';select p.spid from v$session s, v$process p where s.paddr = p.addr and s.sid = &1 and s.serial# = &2;