暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

ORA-600: [krfg_first_barrier1]

老杨 2019-04-18
514

问题描述

客户在打开FLASHBACK的时候碰到了这个错误。

详细的错误如下:

Tue Oct 18 10:55:02 2011
ALTER DATABASE MOUNT
Tue Oct 18 10:55:06 2011
Setting recovery target incarnation TO 1
Tue Oct 18 10:55:06 2011
Successful mount OF redo thread 1, WITH mount id 830459142
Tue Oct 18 10:55:06 2011
DATABASE mounted IN Exclusive Mode
Completed: ALTER DATABASE MOUNT
Tue Oct 18 13:05:08 2011
ALTER SYSTEM SET db_recovery_file_dest_size='200G' SCOPE=BOTH;
Tue Oct 18 13:05:13 2011
ALTER SYSTEM SET db_recovery_file_dest='/flashback' SCOPE=BOTH;
Tue Oct 18 13:05:17 2011
ALTER SYSTEM SET db_flashback_retention_target=4320 SCOPE=BOTH;
Tue Oct 18 13:06:00 2011
Shutting down instance: further logons disabled
Tue Oct 18 13:06:00 2011
Stopping background process CJQ0
Tue Oct 18 13:06:00 2011
Stopping background process MMNL
Tue Oct 18 13:06:01 2011
Stopping background process MMON
Tue Oct 18 13:06:02 2011
Shutting down instance (immediate)
License high water mark = 1
Tue Oct 18 13:06:02 2011
Stopping Job queue slave processes, flags = 7
Tue Oct 18 13:06:02 2011
Job queue slave processes stopped
Tue Oct 18 13:06:02 2011
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Tue Oct 18 13:06:02 2011
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due TO shutdown: 1089
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due TO shutdown: 1089
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active
Tue Oct 18 13:07:29 2011
Starting ORACLE instance (normal)
sskgpgetexecname failed TO GET name
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune OF undo retention IS turned ON. 
IMODE=BR
ILAT =616
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
ksdpec: called FOR event 13740 prior TO event GROUP initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters WITH non-DEFAULT VALUES:
_trace_files_public = TRUE
processes = 2800
sessions = 5600
timed_statistics = TRUE
__shared_pool_size = 905969664
shared_pool_size = 838860800
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
shared_pool_reserved_size= 83886080
nls_language = american
nls_territory = america
nls_sort = BINARY
nls_date_format = DD-MON-RR
nls_numeric_characters = .,
nls_comp = BINARY
nls_length_semantics = CHAR
sga_target = 8589934592
control_files = /oradata/accdb/cntrl01.dbf, /oradata/accdb/cntrl02.dbf, /oradata/accdb/cntrl03.dbf
db_block_checksum = TRUE
db_block_size = 8192
__db_cache_size = 7633633280
compatible = 10.2.0
log_archive_config = DG_CONFIG=(ACCDB,ACCPRI)
log_archive_dest_1 = LOCATION=/archlog
log_archive_dest_2 = SERVICE=ACCDB LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ACCDB
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable
log_archive_max_processes= 3
fal_client = ACCPRI
fal_server = ACCDB
log_buffer = 14230528
log_checkpoint_interval = 100000
log_checkpoint_timeout = 1200
db_files = 512
db_recovery_file_dest = /flashback
db_recovery_file_dest_size= 214748364800
standby_file_management = AUTO
log_checkpoints_to_alert = FALSE
db_flashback_retention_target= 4320
dml_locks = 10000
undo_management = AUTO
undo_tablespace = APPS_UNDOTS1
db_block_checking = FALSE
db_domain = ccic
global_names = TRUE
session_cached_cursors = 500
utl_file_dir = /usr/tmp, /usr/tmp, /oracle/accdb/10.2.0/appsutil/outbound/ACCDB_accountdb, /usr/tmp
plsql_native_library_dir = /oracle/accdb/10.2.0/plsql/nativelib
plsql_native_library_subdir_count= 149
plsql_code_type = INTERPRETED
plsql_optimize_level = 2
job_queue_processes = 2
_system_trig_enabled = TRUE
cursor_sharing = EXACT
parallel_min_servers = 0
parallel_max_servers = 8
background_dump_dest = /oracle/admin/ACCDB/bdump
user_dump_dest = /oracle/admin/ACCDB/udump
max_dump_file_size = 20480
core_dump_dest = /oracle/admin/ACCDB/cdump
db_name = ACCDB
db_unique_name = ACCPRI
open_cursors = 1000
_sort_elimination_cost_ratio= 5
_b_tree_bitmap_plans = FALSE
_fast_full_scan_enabled = FALSE
_sqlexec_progression_cost= 2147483647
_like_with_bind_as_equality= TRUE
pga_aggregate_target = 4294967296
workarea_size_policy = AUTO
optimizer_secure_view_merging= FALSE
aq_tm_processes = 1
olap_page_pool_size = 41943040
PMON started WITH pid=2, OS id=3736548
PSP0 started WITH pid=3, OS id=5767232
MMAN started WITH pid=4, OS id=2556302
DBW0 started WITH pid=5, OS id=5112274
DBW1 started WITH pid=6, OS id=4457358
DBW2 started WITH pid=7, OS id=3604948
DBW3 started WITH pid=8, OS id=4915548
LGWR started WITH pid=9, OS id=3867168
CKPT started WITH pid=10, OS id=2818092
SMON started WITH pid=11, OS id=2949892
RECO started WITH pid=12, OS id=4063580
CJQ0 started WITH pid=13, OS id=4785010
MMON started WITH pid=14, OS id=4588312
MMNL started WITH pid=15, OS id=3015526
Tue Oct 18 13:07:31 2011
ALTER DATABASE MOUNT
Tue Oct 18 13:07:35 2011
Setting recovery target incarnation TO 1
Tue Oct 18 13:07:35 2011
Successful mount OF redo thread 1, WITH mount id 830491155
Tue Oct 18 13:07:35 2011
DATABASE mounted IN Exclusive Mode
Completed: ALTER DATABASE MOUNT
Tue Oct 18 13:07:55 2011
ALTER DATABASE flashback ON
Tue Oct 18 13:07:55 2011
db_recovery_file_dest_size OF 204800 MB IS 0.01% used. This IS a
user-specified LIMIT ON the amount OF SPACE that will be used BY this
DATABASE FOR recovery-related files, AND does NOT reflect the amount OF
SPACE available IN the underlying filesystem OR ASM diskgroup.
Allocated 15265600 bytes IN shared pool FOR flashback generation buffer
Starting background process RVWR
RVWR started WITH pid=17, OS id=4260856
Tue Oct 18 13:07:55 2011
Flashback DATABASE Enabled 
Tue Oct 18 13:07:55 2011
Errors IN file /oracle/admin/ACCDB/udump/accdb_ora_4129208.trc:
ORA-00600: internal error code, arguments: [krfg_first_barrier1], [1], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE flashback ON...


专家解答

之所以要列出这么多的记录是有意义的,对于一般的ORA-600而言,只需要后面4行而已,但是对于当前的问题是不够的,事实上如果不是篇幅,我打算把整个alert文件中的内容都贴上。
简单介绍一下情况,客户打算在STANDBY数据库上打开FLASHBACK,这样备库可以打开进行读写修改,在修改完毕后,可以恢复到打开之前的状态,再次转换成STANDBY数据库的角色,而不需要由于备库的打开,重建整个STANDBY数据库。
本来这个操作在客户这边已经进行过几次,从来没有碰到过什么问题,不过这次这个数据库的STANDBY环境是新建立的,而FLASHBACK这种新技术,碰到什么bug也不奇怪。
发现这个错误后,首先去metalink上查询,结果发现这个错误在metalink上根本没有记录,看来这时一个出现几率很低的问题。虽然FLASHBACK用的人比较少,但是从10g出现,到11.2,还是经历了一段时间了,如果是常规的问题,不太可能没有任何记录。
详细的错误日志文件:
Dump file /oracle/admin/ACCDB/udump/accdb_ora_4129208.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/db10gr2
System name: AIX
Node name: Paccdb2
Release: 1
Version: 6
Machine: 00F67AD94C00
Instance name: ACCDB
Redo thread mounted by this instance: 1
Oracle process number: 16
Unix process pid: 4129208, image: oracle@Paccdb2 (TNS V1-V3)
*** ACTION NAME:() 2011-10-18 13:07:55.437
*** MODULE NAME:(sqlplus@Paccdb2 (TNS V1-V3)) 2011-10-18 13:07:55.437
*** SERVICE NAME:() 2011-10-18 13:07:55.437
*** SESSION ID:(5586.3) 2011-10-18 13:07:55.437
*** 2011-10-18 13:07:55.437
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [krfg_first_barrier1], [1], [], [], [], [], [], []
Current SQL statement for this session:
alter database flashback on
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————– —————————-
ksedst+001c bl ksedst1 000000000 ? 000000000 ?
ksedmp+0290 bl ksedst 104A52AA8 ?
ksfdmp+0018 bl 03F4E238
kgerinv+00dc bl _ptrgl
kgeasnmierr+004c bl kgerinv 000000000 ? 000000000 ?
000009732 ? 00147AE14 ?
700000010018078 ?
krfg_first_barrier_ bl kgeasnmierr 110196398 ? 110490040 ?
w_fba+00e8 104C03194 ? 100000001 ?
000000000 ? 000000001 ?
104C03D84 ? 1056A1010 ?
krfg_first_barrier+ bl krfg_first_barrier_ 000000000 ? 000000000 ?
001c w_fba 000000000 ? 004D25FF8 ?
krf_enable_flashbac bl krfg_first_barrier
k_db+0098
adbdrv+d9b0 bl krf_enable_flashbac 000000000 ?
k_db
opiexe+2c18 bl adbdrv
opiosq0+19f0 bl opiexe 000000000 ? 000000000 ?
FFFFFFFFFFF8EB0 ?
kpooprx+0168 bl opiosq0 3EC779438 ? 700000010003520 ?
7000001EC7793B8 ?
A4000110196398 ?
kpoal8+0400 bl kpooprx FFFFFFFFFFFB704 ?
FFFFFFFFFFFB470 ?
1B0000001B ? 100000001 ?
000000000 ? A40000000000A4 ?
000000000 ? 1103A80D8 ?
opiodr+0ae0 bl _ptrgl
ttcpip+1020 bl _ptrgl
opitsk+1124 bl ttcpip 1100CB7A0 ? FFFFFFFFFFFBA00 ?
000000000 ? 11044F7B0 ?
FFFFFFFFFFFB970 ?
442442226B736800 ?
9000000000D9B74 ? 110451E00 ?
opiino+0990 bl opitsk 1E00000000 ? 000000000 ?
opiodr+0ae0 bl _ptrgl
opidrv+0484 bl 01FBA1C8
sou2o+0090 bl opidrv 3C02ABB45C ? 4A0071EB0 ?
FFFFFFFFFFFF640 ?
opimai_real+01bc bl 01FB7F8C
main+0098 bl opimai_real 000000000 ? 000000000 ?
__start+0070 bl main 000000000 ? 000000000 ?
——————— Binary Stack Dump ———————
简略的看了一下TRACE文件,并没有发现可疑的地方,查询了一下数据库的状态:

SQL> SELECT name, log_mode, controlfile_type, open_mode, database_role, flashback_on FROM v$database;
NAME       LOG_MODE        CONTROLFILE_TY OPEN_MODE  DATABASE_ROLE   FLASHBACK_ON
---------- --------------- -------------- ---------- --------------- ---------------
ACCDB      ARCHIVELOG      BACKUP         MOUNTED    PRIMARY         YES

虽然报了ORA-600错误,但是FLASHBACK已经打开了,而且在对应的未知也发现FLASHBACK日志文件成功创建。此外还有一个疑点,就是控制文件和数据库的角色不正确,按道理来说,控制文件的状态应该是STANDBY,而数据库的角色也应该是STANDBY。于是和具体操作的DBA沟通了一下,发现了问题的所在。
原来这个STANDBY环境还根本没有建立起来,现在数据库只是利用BACKUP的控制文件恢复了控制文件而已,数据库的数据文件还根本就没有恢复,也就是说不但没有建立成STANDBY环境,数据库本身还不存在,这时候开启FLASHBACK当然会有问题。
正常应该先创建STANDBY环境,确认主库和备库之间关系建立且日志应用正常,然后在备库上开启FLASHBACK。这样看来,这个ORA-600错误在metalink上找不到也是正常的,毕竟这个错误太低级了。
不过Oracle应该将错误信息更明确一些,而不是报一个一般人都看不懂的ORA-600错误就完事了,从这个角度讲,这个问题也算是一个小bug。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论