Windows Server 2008 SP1 for Itanium-Bas...-ORA-03113: end-of-file on communication...-oracle 11g 断电后无法启动 ora 00600 kcratr_scan_lastbwr 修复小计

当前位置: 数据库>oracle

本页文章导读:

▪Windows Server 2008 SP1 for Itanium-Based System上安装oracle 10g R2成功 1、oracle 10g 的下载，网站找个地址，发现需要用户名及密码，把地址直接复制进迅雷后，就可以下了。2、我的这个服务器操作系统是64位的，但是不知道为什么，就是不能装64位的oracle，但是.........

▪ORA-03113: end-of-file on communication channel Process ID: 252 Session ID: 1 Serial number: 3 进入字符界面：sqlplus / as sysdbastartup nomount;alter database mount;alter database open;报如下错误：*ERROR at line 1:ORA-03113: end-of-file on communication channelProcess ID: 252Session ID: 1 Serial number: 3 我也从来没.........

▪oracle 11g 断电后无法启动 ora 00600 kcratr_scan_lastbwr 修复小计首先报的是无法连接通过修改监听文件里面的sid 和 tns 里面的sid 解决了然后无法用普通用户登录管理员可以登录但是无法访问任何表查看错误日志提示 ora 00600 kcratr_scan_lastbwr 通过cmd sq.........

[1]Windows Server 2008 SP1 for Itanium-Based System上安装oracle 10g R2成功

来源: 发布时间: 2013-10-29

1、oracle 10g 的下载，网站找个地址，发现需要用户名及密码，把地址直接复制进迅雷后，就可以下了。

2、我的这个服务器操作系统是64位的，但是不知道为什么，就是不能装64位的oracle，但是能装32位的，不知道为什么，只好将就了。

3、修改相应的验证文件夹来支持Windows Server 2008,进入/install/oraparam.ini,在Windows后面加入6.1，如下：

[Certified Versions]
#You can customise error message shown for failure, provide value for CERTIFIED_VERSION_FAILURE_MESSAGE
#Windows=4.0,5.0,5.1,5.2

4、进入/stage/prereq/db/refhost.xml加入

<OPERATING_SYSTEM>

</OPERATING_SYSTEM>

5.右击setup.exe,"兼容性"选项，选择用兼容模式运行这个程序，选择Windows Server 2003（Service Pack1)

6.以后步骤与其他系统下一样。

本文链接

[2]ORA-03113: end-of-file on communication channel Process ID: 252 Session ID: 1 Serial number: 3

来源: 发布时间: 2013-10-29

进入字符界面：

sqlplus / as sysdba

startup nomount;

alter database mount;

alter database open;

报如下错误：

*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 252
Session ID: 1 Serial number: 3

我也从来没有遇到这个错误，只好上google 搜索，看了一堆资料。

其中有一篇文章

http://www.dbanotes.net/Oracle/ORA-03113.htm

提醒了我，其实遇到数据库出错的时候，最先需要做的事就是查看

alter_orcl.log 这个文件。这个不是技术，而是方法论

然后去找 app/admin/orcl/bdump 目录下的alter 告警文件。

c:/> sqlplus / nolog

sql> conn / as sysdba

　　　　Connected to an idle instance.

sql> startup nomount

ORACLE instance started.

Total System Global Area 426852352 bytes
Fixed Size                  　　1375060 bytes
Variable Size                    301991084 bytes
Database Buffers             117440512 bytes
Redo Buffers                    6045696 bytes

sql> alter database mount;

Database altered.

到这一个步骤，就停下来。

大家知道

nomount 状态数据库获取spfile的配置来启动数据库，其实这个时候我就可以

通过 show parameter 查看 background_dump_dest 这个参数来了解

alter 文件到底存放在那里了。

mount 状态，数据库实例已经获取了控制文件。控制文件里面有scn

有数据文件的指针，等等很多信息。

background_dump_dest d:/app/diag/rdbms/orcl/orcl/trace

知道告警文件在什么地方，那就去查看和分析吧。

Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile D:/APP/PRODUCT/11.2.0/DBHOME_1/DATABASE/SPFILEORCL.ORA
System parameters with non-default values:
processes                = 150
memory_target            = 408M
control_files            = "D:/APP/ORADATA/ORCL/CONTROL01.CTL"
control_files            = "D:/APP/FLASH_RECOVERY_AREA/ORCL/CONTROL02.CTL"
db_block_size            = 8192
compatible               = "11.2.0.0.0"
log_archive_format       = "ARC%S_%R.%T"
db_recovery_file_dest    = "D:/app/flash_recovery_area"
db_recovery_file_dest_size= 4977M
undo_tablespace          = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain                = ""
dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
audit_file_dest          = "D:/APP/ADMIN/ORCL/ADUMP"
audit_trail              = "DB"
db_name                  = "orcl"
open_cursors             = 300
diagnostic_dest          = "D:/APP"
Fri Feb 18 19:11:07 2011
PMON started with pid=2, OS id=2188
Fri Feb 18 19:11:07 2011
VKTM started with pid=3, OS id=2788 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Fri Feb 18 19:11:07 2011
GEN0 started with pid=4, OS id=3896
Fri Feb 18 19:11:07 2011
DIAG started with pid=5, OS id=248
Fri Feb 18 19:11:07 2011
DBRM started with pid=6, OS id=936
Fri Feb 18 19:11:07 2011
PSP0 started with pid=7, OS id=2972
Fri Feb 18 19:11:07 2011
DIA0 started with pid=8, OS id=2976
Fri Feb 18 19:11:07 2011
MMAN started with pid=9, OS id=3044
Fri Feb 18 19:11:07 2011
DBW0 started with pid=10, OS id=1308
Fri Feb 18 19:11:07 2011
LGWR started with pid=11, OS id=2092
Fri Feb 18 19:11:07 2011
CKPT started with pid=12, OS id=2264
Fri Feb 18 19:11:07 2011
SMON started with pid=13, OS id=3516
Fri Feb 18 19:11:07 2011
RECO started with pid=14, OS id=664
Fri Feb 18 19:11:07 2011
MMON started with pid=15, OS id=2164
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Feb 18 19:11:08 2011
MMNL started with pid=16, OS id=3788
starting up 1 shared server(s) ...
ORACLE_BASE from environment = D:/app
Fri Feb 18 19:11:42 2011
alter database mount
Fri Feb 18 19:11:46 2011
Successful mount of redo thread 1, with mount id 1271263854
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount
Fri Feb 18 19:12:49 2011
alter database open
Fri Feb 18 19:12:49 2011
LGWR: STARTING ARCH PROCESSES
Fri Feb 18 19:12:49 2011
ARC0 started with pid=20, OS id=2072
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Fri Feb 18 19:12:50 2011
ARC1 started with pid=21, OS id=356
Fri Feb 18 19:12:50 2011
ARC2 started with pid=22, OS id=3132
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Fri Feb 18 19:12:50 2011
ARC3 started with pid=23, OS id=1020
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_arc1_356.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 5218762752 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_arc1_356.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 47236096 bytes disk space from 5218762752 limit
ARC1: Error 19809 Creating archive log file to 'D:/APP/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2011_02_18/O1_MF_1_179_%U_.ARC'
ARCH: Archival stopped, error occurred. Will continue retrying
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_arc1_356.trc:
ORA-16038: log 2 sequence# 179 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 2 thread 1: 'D:/APP/ORADATA/ORCL/REDO02.LOG'
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_ora_4068.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 5218762752 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_ora_4068.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 44871680 bytes disk space from 5218762752 limit
ARCH: Error 19809 Creating archive log file to 'D:/APP/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2011_02_18/O1_MF_1_178_%U_.ARC'
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Errors in file d:/app/diag/rdbms/orcl/orcl/trace/orcl_ora_4068.trc:
ORA-16038: log 1 sequence# 178 cannot be archived
ORA-19809: limi

[3]oracle 11g 断电后无法启动 ora 00600 kcratr_scan_lastbwr 修复小计

来源: 发布时间: 2013-10-29

首先报的是无法连接通过修改监听文件里面的sid 和 tns 里面的sid 解决了

然后无法用普通用户登录管理员可以登录但是无法访问任何表

查看错误日志提示

ora 00600 kcratr_scan_lastbwr

通过cmd

sqlplus sde/sde@"orcl as sysdba"

以管理员身份连接orcl实例

SQL>shutdown immediate
SQL>startup mount
SQL>recover database
SQL>alter database open;

然后重启一下orcl实例

解决

本文链接