分类目录归档：Oracle

linux6 安装Oracle 19c主要报错记录

发表于 2019 年 10 月 7 日由惜分飞

在某些极端情况下,需要在linux 6上面安装Oracle 19C(没有通过官方认证),这里进行了一些测试,安装实施成功,主要问题记录如下:
系统信息

[root@ora11g ~]# more /etc/issue
Oracle Linux Server release 6.9
Kernel \r on an \m

[root@ora11g ~]# uname -r  
4.1.12-61.1.28.el6uek.x86_64

[FATAL] [INS-30060] Check for group existence failed

通过./runInstaller -ignoreInternalDriverError解决
参考:Oracle 18c on RHEL 6.10 fail with “[FATAL] [INS-30060] Check for group existence failed.” (Doc ID 2464358.1)

安装完成之后,sqlplus启动报错

[oracle@ora11g ~]$ sqlplus -v
sqlplus: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /u02/app/oracle/product/19.2/db_1/lib/libclntsh.so.19.1)
sqlplus: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /u02/app/oracle/product/19.2/db_1/lib/libclntshcore.so.19.1)
sqlplus: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /u02/app/oracle/product/19.2/db_1/lib/libnnz19.so)

主要是由于19C要求glibc-2.14,但是该系统版本情况如下

[root@ora11g ~]# strings /lib64/libc.so.6 |grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE

安装glibc-2.14

[root@ora11g ~]# wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
[root@ora11g ~]# mv glibc-2.14.tar.gz /opt/software
[root@ora11g ~]# cd /opt/software
[root@ora11g software]# tar xf glibc-2.14.tar.gz
[root@ora11g software]# cd glibc-2.14
[root@ora11g glibc-2.14]# mkdir build
[root@ora11g glibc-2.14]# cd build
[root@ora11g build]# ../configure --prefix=/usr/local/glibc-2.14
[root@ora11g build]# make -j4
[root@ora11g build]# make install
[root@ora11g build]# cd /usr/local/glibc-2.14/lib
[root@ora11g lib]# cp libc-2.14.so /lib64/
[root@ora11g lib]# cd /lib64
[root@example lib64]# /sbin/sln libc-2.14.so /lib64/libc.so.6
[root@ora11g lib64]# strings /lib64/libc.so.6 |grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_PRIVATE

sqlplus工作做正常

[oracle@ora11g ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Sun Oct 6 15:53:10 2019
Version 19.2.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> exit

dbca DBT-50000 DBT-50001报错处理

通过dbca -J-Doracle.assistants.dbca.validate.ConfigurationParams=false 解决

发表在 ORACLE 19C, Oracle安装升级 | 标签为 /lib64/libc.so.6: version `GLIBC_2.14', DBT-50000, DBT-50001, INS-30060 | 评论关闭

再一起asm disk被格式化成ext3文件系统故障恢复

发表于 2019 年 10 月 6 日由惜分飞

国庆节前夕接到朋友求救电话asm disk被格式化成ext3格式了,具体操作如下

并且把这个分区直接挂载到/目录

由于/被挂载新格式化的控盘,导致asm磁盘组访问其他盘报错

Sun Sep 29 18:15:02 2019
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_b000_8094.trc:
ORA-15025: could not open disk "/dev/asmdisk/sdh"
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_b000_8094.trc:
ORA-15025: could not open disk "/dev/asmdisk/sdh"
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
WARNING: cache failed reading from group=1(DATA) fn=9 blk=0 count=1 from 
disk= 5 (DATA_0005) kfkist=0x20 status=0x02 osderr=0x0 file=kfc.c line=11596
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_b000_8094.trc:
ORA-15025: could not open disk "/dev/asmdisk/sdh"
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-15080: synchronous I/O operation to a disk failed
WARNING: cache succeeded reading from group=1(DATA) fn=9 blk=0 count=1 from 
disk= 7 (DATA_0007) kfkist=0x20 status=0x01 osderr=0x0 file=kfc.c line=11637
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_b000_8094.trc:
ORA-15025: could not open disk "/dev/asmdisk/sdh"
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
WARNING: PST-initiated drop of 1 disk(s) in group 1(.2380027701))

重启系统之后,重试mount 磁盘组

GMON dismounting group 1 at 18 for pid 31, osid 44279
NOTE: Disk DATA_0000 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0001 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0002 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0003 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0004 in mode 0x1 marked for de-assignment
NOTE: Disk DATA_0005 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0006 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0007 in mode 0x7f marked for de-assignment
NOTE: Disk  in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0009 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0010 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0011 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0012 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0013 in mode 0x7f marked for de-assignment
NOTE: Disk DATA_0014 in mode 0x7f marked for de-assignment
ERROR: diskgroup DATA was not mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "8" is missing from group number "1" 
ERROR: ALTER DISKGROUP DATA MOUNT  /* asm agent *//* {1:2587:2} */

由于sdb（asm disk 8）被格式化,导致data磁盘组无法正常mount.这个客户运气比较好data 磁盘组是normal模式,但是由于mount到/,导致disk 4被强制drop,因此无法mount成功,但是通过一系列处理数据实现完美恢复,0数据丢失

如果磁盘组是外部冗余,请参考:
又一例asm格式化文件系统恢复
一次完美的asm disk被格式化ntfs恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统

发表在非常规恢复 | 标签为 asm disk ext3, asm disk 格式化, ORA-15040 ORA-15042, ORA-15042 | 评论关闭

ORA-600 ktfbhget-4

发表于 2019 年 9 月 27 日由惜分飞

有客户和我们反馈,他们数据库现在使用异常,查询dba_data_files报ORA-600 ktfbhget-4

*** 2019-09-21 13:56:42.944
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ktfbhget-4], [384], [16], [], [], [], [], []
Current SQL statement for this session:
select tablespace_name from dba_data_files
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               1028F23AC ?
ksfdmp+0018          bl       01FD7F4C             
kgerinv+00e8         bl       _ptrgl               
kgesinv+0020         bl       kgerinv              000000000 ? 000000000 ?
                                                   FFFFFFFFFFF8920 ? 000400002 ?
                                                   000000000 ?
ksesin+005c          bl       kgesinv              7000001637868E8 ? 110359FD8 ?
                                                   000000100 ? 000007FFF ?
                                                   000007FFF ?
ktfbhget+047c        bl       ksesin               1029B1D18 ? 200000002 ?
                                                   000000000 ? 000000180 ?
                                                   000000000 ? 000000010 ?
                                                   000000008 ? 000000000 ?
ktfbhcf+03c0         bl       ktfbhget             FFFFFFFFFFF8DA0 ? 1103589D8 ?
                                                   201035A57C ? 1C610005A40 ?
qerfxFetch+0c94      bl       01FD7AC4             
qerjoFetch+037c      bl       _ptrgl               
rwsfcd+0060          bl       _ptrgl               
qersoFetch+0108      bl       _ptrgl               
qerjoFetch+037c      bl       _ptrgl               
qerjoFetch+037c      bl       _ptrgl               
rwsfcd+0060          bl       _ptrgl               
qeruaFetch+0140      bl       01FD7AC4             
qervwFetch+008c      bl       01FD7AC4             
opifch2+0c68         bl       01FD7AC4             
opiall0+1244         bl       opifch2              7000001626B2F28 ? 100000001 ?
                                                   FFFFFFFFFFFA3D8 ?
kpoal8+0a68          bl       opiall0              5E1000C818 ? 2200000014 ?
                                                   FFFFFFFFFFFAAD8 ? 000000000 ?
                                                   FFFFFFFFFFFAA28 ? 11028C2C8 ?
                                                   080000000 ? 4000000007FFF ?
opiodr+08e8          bl       _ptrgl               
ttcpip+0c54          bl       _ptrgl               
opitsk+0c28          bl       ttcpip               11000C818 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
opiino+0798          bl       opitsk               000000000 ? 000000000 ?
opiodr+08e8          bl       _ptrgl               
opidrv+032c          bl       opiodr               3C00000018 ? 4101F5E80 ?
                                                   FFFFFFFFFFFF4C0 ? 0A000FD98 ?
sou2o+0028           bl       opidrv               3C0C000000 ? 400000000 ?
                                                   FFFFFFFFFFFF4C0 ?
main+0138            bl       01FD758C             
__start+0098         bl       main                 000000000 ? 000000000 ?

通过询问知道由于file#=17最初由于裸设备权限异常,导致无法访问,执行了delete from file$ where file#=17,然后遭遇异常又人工插入了一条file#=17的记录到file$中,但是由于不知道具体值,可能是由于部分值插入错误引起现在问题.

通过分析file$表定义

create table file$                                             /* file table */
( file#         number not null,                   /* file identifier number */
  status$       number not null,                      /* status (see KTS.H): */
                                               /* 1 = INVALID, 2 = AVAILABLE */
  blocks        number not null,                   /* size of file in blocks */
                                           /* zero for bitmapped tablespaces */
  ts#           number,                         /* tablespace that owns file */
  relfile#      number,                              /* relative file number */
  maxextend     number,                                 /* maximum file size */
  inc           number,                                  /* increment amount */
  crscnwrp      number,                                 /* creation SCN wrap */
  crscnbas      number,                                 /* creation SCN base */
  ownerinstance varchar("M_IDEN"),                    /* Owner instance name */
  spare1        number,      /* tablespace-relative DBA of space file header */
                                   /* NULL for dictionary-mapped tablespaces */
  spare2        number,
  spare3        varchar2(1000),
  spare4        date
)

通过dump文件头(文件创建大小/SCN等),结合一些计算和经验值,获取到相关值重新插入正确值,一切恢复正常

delete from file$ where file#=17 and ts#=384;
insert into sys.file$ (FILE#, STATUS$, BLOCKS, TS#, RELFILE#, MAXEXTEND, INC,
 CRSCNWRP, CRSCNBAS, OWNERINSTANCE, SPARE1, SPARE2, SPARE3, SPARE4)
values (17,2,256000,384,17,0,0,3087,1631091037,null,71303170, null, null, null);
commit;

再次提醒,file$中记录请勿人工修改,以前写过相关casefile$ 删除记录恢复(delete file$ recovery)

发表在非常规恢复 | 标签为 ktfbhget-4, ORA-600 ktfbhget-4 | 评论关闭

17813235971

QQ 咨询

分类目录归档：Oracle

linux6 安装Oracle 19c主要报错记录

再一起asm disk被格式化成ext3文件系统故障恢复

ORA-600 ktfbhget-4

文章分类

最近发表

分类目录归档：Oracle

linux6 安装Oracle 19c主要报错记录

再一起asm disk被格式化成ext3文件系统故障恢复

ORA-600 ktfbhget-4

标签云

文章分类

最近发表