移动数据文件从ASM到文件系统
测试环境:ORACLE 10.2.0.4+ ASM有两种方法可以实现从ASM到文件系统的数据文件移动1、 数据库RUNNING状态在数据库处于OPEN状态时,要想移动数据库从ASM到文件系统,则必须使相关表空...
从ASM磁盘中拷贝文件到本地文件系统
本文介绍如何从ASM磁盘中拷贝文件到本地文件系统测试环境:ORACLE 10.2.0.4 + ASM1、 在目标数据库上创建一个(源)目录(source_dir)SQL>create or replace directory source_dir as '+xiner_data/xiner/...
恢复RAC数据库到单实例(ASM)
源端为10.2.0.4的RAC+ASM,现通过热备并应用归档日志的方式将数据库恢复到相同版本的单实例上,单机也同样采用ASM方式。单机环境为:ORACLE 10.2.0.4 , ASM1、 将从生产机上ftp过来的pfile.ora文件进...
使用CHECKSYNTAX命令检查RMAN脚本是否存在语法错误
在生产环境中,假如要部署一套RMAN的备份脚本,那么对脚本的测试就是必不可少的环节,Oracle提供了CHECKSYNTAX命令来协助我们在不用实际执行脚本的情况下检查脚本的语法错误,如:[oracle@ligle-db ~]$ ...
online redo log损坏,启动报:ORA-00313和ORA-00312
今天打开虚拟机中的一个DB,这个DB好久没打开过了,在执行STARTUP启动时报错:[oracle@ligle-db admin]$ sqlplus '/assysdba' SQL*Plus: Release 10.2.0.4.0 - Productionon Mon Mar 28 14:0...
关于加快INSERT语句执行速度的测试
第一种情况(非归档模式下)创建表T01:SQL> createtable t01 as select * from dba_objects where 1=2;Table created.(非归档模式下)查看当前redo大小:SQL> selectvalue2 fromv$mystat...
ORA-12838
今天在做实验时发现连着执行两边下面的SQL语句时,就报如下错误:SQL> insert /*+ append */ into t01 nologging select *from dba_objects;insert /*+ append */ into t01 nologging select * from...
关于加快INSERT语句执行速度和 HINT /*+ append*/及nologging的使用
(非归档模式下)创建表T01: SQL> create table t01 as select * from dba_objects where 1=2; Table created. (非归档模式下)查看当前redo大小: SQL> select value 2 from v$mystat,v$statname 3 where v$mystat.statistic#=v$statname.statistic# 4 and v$statname.name='redo size' 5 / VALUE ---------- 49784 (非归档模式下)普通INSERT语句插入: SQL> insert into t01 select * from dba_objects; 11698 rows create
Backing Up Logs with BACKUP … PLUS ARCHIVELOG
/* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:5.0pt; mso-para-margin-right:0cm; mso-para-margin-bottom:0cm; mso-para-margin-left:0cm; mso-para-margin-bottom:.0001pt; mso-para-margin-top:1.0gd; mso-para-margin-right:0cm; mso-para-margin-bottom:0cm;
关于使用Flash Recovery Area后一些初始化参数的使用限制
/* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:5.0pt; mso-para-margin-right:0cm; mso-para-margin-bottom:0cm; mso-para-margin-left:0cm; mso-para-margin-bottom:.0001pt; mso-para-margin-top:1.0gd; mso-para-margin-right:0cm; mso-para-margin-bottom:0cm;
丢失联机重做日志文件的恢复
/* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.5pt; mso-bidi-font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-
ORA-02050
昨天客户反映说在下午某时间段有几个事务失败了,让我查下当时数据库系统的负载是否正常,看了下CPU的历史负载,很正常,于是看了下日志发现有几个timeout错误和一个ORA-02050错误。 Tue Feb 15 20:44:05 2011 Error 1013 trapped in 2PC on transaction 199.40.297416. Cleaning up. Tue Feb 15 20:44:56 2011 Error stack returned to user: ORA-02050: transaction 199.40.297416 rolled back, some remote DBs may be in-doubt ORA-01013: user requested cancel of current operation 这个是分布式事务处理出错的提示
应用程序报ORA-01115错误
应用端查询等操作被异常中止且记录如下信息 ORA-01115: IO error reading block from file 50 (block # 1624) ORA-01110: data file 50: '/dev/ra_dhyx02' ORA-27091: skgfqio: unable to queue I/O ORA-27072: skgfdisp: I/O error IBM AIX RISC System/6000 Error: 5: I/O error ; nested exception is java.sql.SQLException: ORA-01115: IO error reading block from file 50 (block # 1624) ORA-01110: data file 50: '/dev/ra_dhyx02' ORA-27091: skgfqio: unable to queue I/O ORA-27072: skgf
不同备份方法的特性比较
不同备份方法的特性比较: Feature Recovery Manager User-Managed Export Closed database backups Supported.Requires instance to be mounted. Supported. Not supported. Open database backups Supported.No need to use BEGIN/END BACKUP statements Supported.Must use BEGIN/END BACKUP statements. Requires rollback or undo segments to gene
版本9204中的内部错误:ORA-00600[qmxiUnpPacked2]
在客户的综合结算数据库系统的日志中发现如下错误: Mon Sep 20 15:16:04 2010 Errors in file /settle/oracle/admin/zhjs/udump/zhjs_ora_995502.trc: ORA-00600: internal error code, arguments: [qmxiUnpPacked2], [121], [], [], [], [], [], [] trace文件zhjs_ora_995502.trc的内容: /settle/oracle/admin/zhjs/udump/zhjs_ora_995502.trc Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.8.0 – Produc
Crash recovery和Media recovery的区别
Datafile media recovery(often simply called media recovery) is the most basic form of user-initiated data recovery. Crash recovery process is a special form of recovery,witch happens the first time an Oracle database instance is started after a crash (or SHUTDOWN ABORT).In Crash recovery,the goal is to bring the datafiles to a transaction-consistent state,preserving all committed changes up to the point when the instance failed. 两者的重要区别: 1、Media recovery must be expli
oracle 10204终结版psu昨天发布(10.2.0.4.9)
文章转自:http://www.killdb.com/?p=190一直没太关注,比较忙,今天写报告,才发现10.2版本的最终版psu昨天发布了(2011年7月19日) 该psu不大,我看了下,仅仅6m左右,喜欢尝鲜的朋友可以试试,如下是摘取我写的报告中的部分: 2011年7月19日发布了oracle 10.2.0.4的最终psu(除Solaris x86 (32-bit) and Apple Mac OS X 外), 版本为10.2.0.4.9 ,目前10.2版本PSU 列表如下: Oracle Database Patch Set Update Unix Comments 10.2.0.4.1 8576156
enq: DX – contention和inactive transaction branch
最近一个月数据库中总是存在两种等待事件: enq: DX – contention和inactive transaction branch 一开始怀疑是bug,但总是对不上号,几乎都打算开sar求助了,呵呵~ 我的数据库版本是10.2.0.4,AIX 5.3 今下午又研究了好一会,最后决定将持有该等待事件的会话进程kill掉,因为明显不是应用用户在使用,而是其他的用户。kill完之后,发现并没有人反映问题,并且这两个等待事件也消失了…,无语! 其实遇到DX锁,目前真的想不出什么好的处理办法来,要不是bug,要不就kill掉。如果kill掉后,很快就又有DX锁了,那八成是bu
aix平台执行sqlplus报:0509-130 Symbol resolution failed for /usr/lib/libc.a[aio_64.o]
客户说执行sqlplus时报错,详细见下: $ sqlplus 'sys/ligle as sysdba' SQL*Plus: Release 10.2.0.4.0 - Production on Wed Jun 22 08:56:29 2011 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. exec(): 0509-036 Cannot load program oraclebcrm because of the following errors: 0509-130 Symbol resolution failed for /usr/lib/libc.a[aio_64.o] because: 0509-136 Symbol kaio_rdwr64 (number 1) is not exported from dependent module /unix.
因归档目录所在文件系统使用率100%以致dblink连接失败
刚刚客户说crm到prm的dblink有问题,我还觉得dblink能有什么问题,于是看了下,执行了一个简单的select,果真报错,见下: SQL> SELECT * FROM TAB@LINKPRM; SELECT * FROM TAB@LINKPRM * ERROR at line 1: ORA-00257: archiver error. Connect internal only, until freed. ORA-02063: preceding line from LINKPRM 一看archiver字样,就知道是远端归档有问题,应该是归档目录满了,按说归档是2小时一备一清的,难道短短2个小时产生这么的日志么? 首先到prm上一看,归档目录所在文件系统使用率1