标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,769)
- DB2 (22)
- MySQL (77)
- Oracle (1,610)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (592)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
月归档:六月 2013
root 用户操作 ORACLE 数据库导致悲剧
接到同事请求,说客户的linux redhat 5.8平台部署的11.2.0.3 RAC 节点2挂掉了,报磁盘IO异常,数据库hang住
Fri Jun 14 12:01:22 2013 Thread 2 advanced to log sequence 369 (LGWR switch) Current log# 49 seq# 369 mem# 0: +DATA/q9db/onlinelog/group_49.861.817830099 Fri Jun 14 12:01:22 2013 Archived Log entry 89300 added for thread 2 sequence 368 ID 0x35324053 dest 1: Fri Jun 14 14:26:18 2013 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_11788.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_11788.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 WARNING: failed to read mirror side 1 of virtual extent 441 logical extent 0 of file 625 in group [2.3857217523] from disk DATA_0001 allocation unit 377890 reason error; if possible, will try another mirror side Fri Jun 14 14:31:17 2013 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_13767.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_13767.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 WARNING: failed to read mirror side 1 of virtual extent 441 logical extent 0 of file 625 in group [2.3857217523] from disk DATA_0001 allocation unit 377890 reason error; if possible, will try another mirror side
在12点钟数据库运行正常,无任何错误,突然到了14多出现ORA-15025/ORA-27041,并且重启ORACLE 数据库恢复正常。该错误很明显是数据库无权限访问ASM DISK,检查ASM实例日志
Thu Jun 13 19:01:21 2013 ASMB started with pid=25, OS id=25066 Thu Jun 13 19:01:22 2013 NOTE: client +ASM2:+ASM registered, osid 25068, mbr 0x0 WARNING: failed to online diskgroup resource ora.DATA.dg (unable to communicate with CRSD/OHASD) Thu Jun 13 19:01:24 2013 WARNING: failed to online diskgroup resource ora.OCR_VOTE.dg (unable to communicate with CRSD/OHASD) Thu Jun 13 19:01:57 2013 NOTE: client q9db2:q9db registered, osid 25732, mbr 0x1 Thu Jun 13 19:02:31 2013 ALTER SYSTEM SET local_listener=' (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.8.8.33) (PORT=1521))))' SCOPE=MEMORY SID='+ASM2'; Fri Jun 14 14:53:09 2013 SQL> ALTER DISKGROUP OCR_VOTE DISMOUNT /* asm agent *//* {2:61929:97} */ Fri Jun 14 14:53:10 2013 SQL> ALTER DISKGROUP ARCH DISMOUNT /* asm agent *//* {2:61929:97} */ Fri Jun 14 14:53:10 2013 SQL> ALTER DISKGROUP DATA DISMOUNT /* asm agent *//* {2:61929:97} */
这里可以明显的看到,ASM实例在该时间点无任何错误,证明一切运行正常,查看系统日志,在该故障点,message中无任何记录,查看asm disk权限
[oracle@q9db02 trace]$ ll /dev/mapper/ total 0 crw------- 1 root root 10, 60 Jun 9 11:08 control brw-rw---- 1 grid asmdba 253, 15 Jun 14 16:20 q9datalun1 brw-rw---- 1 grid asmdba 253, 16 Jun 14 16:20 q9datalun2 brw-rw---- 1 grid asmdba 253, 17 Jun 14 16:20 q9datalun3 brw-rw---- 1 grid asmdba 253, 18 Jun 14 16:19 q9datalun4 brw-rw---- 1 grid asmdba 253, 19 Jun 14 16:20 q9datalun5 brw-rw---- 1 grid asmdba 253, 20 Jun 14 16:20 q9datalun6 brw-rw---- 1 grid asmdba 253, 21 Jun 14 16:19 q9datalun7 brw-rw---- 1 grid asmdba 253, 4 Jun 14 16:20 q9datalun8 brw-rw---- 1 grid asmdba 253, 5 Jun 14 16:20 q9votelun1
所有文件权限没有任何问题,和当初部署之时完全相同而且运行了一段时间都正常,部署之时权限
[oracle@q9db02 trace]$ more /etc/rc.local chown grid:asmdba /dev/mapper/q9votelun1 chmod 660 /dev/mapper/q9votelun1 chown grid:asmdba /dev/mapper/q9datalun1 chmod 660 /dev/mapper/q9datalun1 chown grid:asmdba /dev/mapper/q9datalun2 chmod 660 /dev/mapper/q9datalun2 chown grid:asmdba /dev/mapper/q9datalun3 chmod 660 /dev/mapper/q9datalun3 chown grid:asmdba /dev/mapper/q9datalun4 chmod 660 /dev/mapper/q9datalun4 chown grid:asmdba /dev/mapper/q9datalun5 chmod 660 /dev/mapper/q9datalun5 chown grid:asmdba /dev/mapper/q9datalun6 chmod 660 /dev/mapper/q9datalun6 chown grid:asmdba /dev/mapper/q9datalun7 chmod 660 /dev/mapper/q9datalun7 chown grid:asmdba /dev/mapper/q9datalun8 chmod 660 /dev/mapper/q9datalun8 chown grid:asmdba /dev/mapper/q9datalun8 chmod 660 /dev/mapper/q9datalun8
因为这里权限没有任何改变,而且asm disk权限正确,系统日志无任何日志,证明该问题不是因为ASM DISK权限改变导致,那我怀疑是人做了不该做的操作,比喻临时性修改了ASM DISK权限,然后有修改回来了,或者是不正常的用户操作了数据库,而这些操作更加可能是root用户操作,分析root用户操作记录
--history部分记录 803 su oracle 804 exit 805 cd /tmp 806 ls 807 cd sysbench/ 808 cd bin/ 809 ls 810 ORACLE_SID=q9db2 811 export ORACLE_BASE 812 export ORACLE_HOME 813 ./sysbench --test=oltp --oltp-table-name=sysbench --oltp-table-size=1 --oracle-db=Q9DB --oracle-user=sysbench --oracle-password=sysbench --db-driver=oracle prepare 814 syssql 815 sqlplus system/sysbench@q9db02 816 sqlplus system/q9db@q9db02 817 echo $ORACLE_HOME 818 cd $ORACLE_HOME/network/ 819 vi admin/tnsnames.ora 820 sqlplus system/NEWQ9DB 821 echo $ORACLE_HOME 822 vi ~/.bash_profile 823 echo $ORACLE_SID 824 ps -ef | grep smon 825 sqlplus system/NEWQ9DB 826 exit
这里很明显的看到,由于SA想使用sysbench做系统基线测试,使用了root用户登录数据库并进行了相关操作,从而出现了该问题,因为ASM DISK 所有者是grid:asmdba,权限是660,root用户无法对ASM DISK进行读写操作,从而出现了上述错误。让同事协助SA重现上述操作,果然出现完全相同的错误,而且退出root session,数据库恢复正常
Fri Jun 14 15:44:24 2013 Archived Log entry 89330 added for thread 2 sequence 389 ID 0x35324053 dest 1: Fri Jun 14 15:50:42 2013 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_29404.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_29404.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun2" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 WARNING: failed to read mirror side 1 of virtual extent 473 logical extent 0 of file 625 in group [2.3857045540] from disk DATA_0001 allocation unit 377894 reason error; if possible, will try another mirror side Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_29404.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun4" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 ORA-00604: error occurred at recursive SQL level 2 ORA-01115: IO error reading block from file (block # ) ORA-01110: data file 1: '+DATA/q9db/datafile/system.625.817825255' ORA-15081: failed to submit an I/O operation to a disk Errors in file /u01/app/oracle/diag/rdbms/q9db/q9db2/trace/q9db2_ora_29404.trc: ORA-15025: could not open disk "/dev/mapper/q9datalun4" ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 3 ORA-00604: error occurred at recursive SQL level 2 ORA-01115: IO error reading block from file (block # ) ORA-01110: data file 1: '+DATA/q9db/datafile/system.625.817825255' ORA-15081: failed to submit an I/O operation to a disk WARNING: failed to read mirror side 1 of virtual extent 652 logical extent 0 of file 625 in group [2.3857045540] from disk DATA_0003 allocation unit 377939 reason error; if possible, will try another mirror side Fri Jun 14 15:55:58 2013 Thread 2 advanced to log sequence 391 (LGWR switch) Current log# 41 seq# 391 mem# 0: +DATA/q9db/onlinelog/group_41.853.817830085 Fri Jun 14 15:55:58 2013 Archived Log entry 89331 added for thread 2 sequence 390 ID 0x35324053 dest 1: Thread 2 advanced to log sequence 392 (LGWR switch) Current log# 42 seq# 392 mem# 0: +DATA/q9db/onlinelog/group_42.854.817830087
在ASM ORACLE RAC环境中,使用root操作oracle 数据库导致该错误,强烈建议:操作oracle数据库,请使用oracle数据库安装用户(最少也是同一个所属组用户)运行,超级用户root对于oracle来说也不是万能的
发表在 Oracle
评论关闭
ORACLE 12C CDB中PDB参数管理机制
在ORACLE 12C中参数文件只是记录了cdb的参数信息,没有记录任何的pdb的信息,那ORACLE是如何管理使得各个pdb有自己的参数,这里通过试验的出来ORACLE 12C CDB环境中是通过参数文件结合PDB_SPFILE$来实现参数管理
数据库版本
SQL> select * from v$version; BANNER CON_ID -------------------------------------------------------------------------------- ---------- Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0 PL/SQL Release 12.1.0.1.0 - Production 0 CORE 12.1.0.1.0 Production 0 TNS for Linux: Version 12.1.0.1.0 - Production 0 NLSRTL Version 12.1.0.1.0 - Production 0
pdb信息
SQL> select PDB_NAME,CON_UID,pdb_id,status from dba_pdbs; PDB_NAME CON_UID PDB_ID STATUS ---------- ---------- ---------- ------------- PDB1 3313918585 3 NORMAL PDB$SEED 4048821679 2 NORMAL PDB2 3872456618 4 NORMAL SQL> select con_id,dbid,NAME,OPEN_MODE from v$pdbs; CON_ID DBID NAME OPEN_MODE ---------- ---------- ------------------------------ ---------- 2 4048821679 PDB$SEED READ ONLY 3 3313918585 PDB1 READ WRITE 4 3872456618 PDB2 MOUNTED
CDB$ROOT中修改参数
--指定container=all SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> alter system set open_cursors=500 container=all; System altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 500 SQL> alter session set container=pdb1; Session altered. SQL> show con_name CON_NAME ------------------------------ PDB1 SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 500 --在CDB$ROOT中修改不指定container参数表示全部pdb生效 SQL> alter session set container=CDB$ROOT; Session altered. SQL> alter system set open_cursors=100; System altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100 SQL> alter session set container=pdb1; Session altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100 --指定container=current SQL> alter system set open_cursors=120 container=current; System altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 120 SQL> alter session set container=pdb2 ; Session altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 120
这里可以看出来,在ROOT中修改参数,默认情况和指定container=all/current均是所有open的pdb都生效.
这里有个疑问ORACLE的参数文件只是记录的cdb的sid的参数,并未记录各个pdb的参数,那是如何实现cdb中各个pdb参数不一致的呢?继续分析
修改pdb参数做10046
SQL> show con_name; CON_NAME ------------------------------ PDB1 SQL> oradebug setmypid Statement processed. SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 Statement processed. SQL> oradebug TRACEFILE_NAME /u01/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_ora_18377.trc SQL> alter system set sessions=100; System altered. SQL> oradebug EVENT 10046 trace name context off Statement processed. --继续修改pdb参数 SQL> alter session set container=pdb1; Session altered. SQL> oradebug setmypid Statement processed. SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 Statement processed. SQL> oradebug TRACEFILE_NAME /u01/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_ora_20275.trc SQL> alter system set sessions=101; System altered. SQL> oradebug EVENT 10046 trace name context off Statement processed.
分析trace文件
--第一次修改pdb参数值 insert into pdb_spfile$(db_uniq_name, pdb_uid, sid, name, value$, comment$) values(:1,:2,:3,:4,:5,:6) END OF STMT PARSE #140085118752824:c=3999,e=3397,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=99767937623 BINDS #140085118752824: Bind#0 oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7fffcfaa5842 bln=32 avl=03 flg=09 value="cdb" Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f681bbb2170 bln=22 avl=06 flg=05 value=3313918585 Bind#2 oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7fffcfaa46f8 bln=32 avl=01 flg=09 value="*" Bind#3 oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=0bc220d8 bln=32 avl=08 flg=09 value="sessions" Bind#4 oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7fffcfaa474c bln=32 avl=03 flg=09 value="100" Bind#5 oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=00000000 bln=32 avl=00 flg=09 --第二次修改pdb参数值(相同参数) update pdb_spfile$ set value$=:5, comment$=:6 where name=:1 and pdb_uid=:2 and db_uniq_name=:3 and sid=:4 BINDS #140603847818408: Bind#0 oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7ffff6477dcc bln=32 avl=03 flg=09 value="101" Bind#1 oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=00000000 bln=32 avl=00 flg=09 Bind#2 oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=0bc220d8 bln=32 avl=08 flg=09 value="sessions" Bind#3 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7fe0e2638320 bln=22 avl=06 flg=05 value=3313918585 Bind#4 oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7ffff6478ec2 bln=32 avl=03 flg=09 value="cdb" Bind#5 oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7ffff6477d78 bln=32 avl=01 flg=09 value="*"
通过这里我们发现在独立修改pdb参数之时,其本质是在pdb_spfile$基表中插入或者修改相关记录(第一次修改插入,后续修改是更新)
关于pdb_spfile$基表分析
SQL> SHOW CON_NAME; CON_NAME ------------------------------ CDB$ROOT SQL> COL OWNER FOR A10 SQL> select con_id,owner,object_type from cdb_objects where object_name='PDB_SPFILE$'; CON_ID OWNER OBJECT_TYPE ---------- ---------- ----------------------- 2 SYS TABLE 1 SYS TABLE 3 SYS TABLE SQL> COL DB_UNIQ_NAME FOR A10 SQL> COL NAME FOR A15 SQL> COL VALUE$ FOR A10 SQL> SELECT DB_UNIQ_NAME,PDB_UID,NAME,VALUE$ FROM PDB_SPFILE$; DB_UNIQ_NA PDB_UID NAME VALUE$ ---------- ---------- --------------- ---------- cdb 3313918585 sessions 101 SQL> ALTER SESSION SET CONTAINER=pdb1; Session altered. SQL> SELECT DB_UNIQ_NAME,PDB_UID,NAME,VALUE$ FROM PDB_SPFILE$; no rows selected
证明pdb中不同于root的参数是记录在root的PDB_SPFILE$基表中.
整个CDB的工作原理是如果在PDB_SPFILE$中无相关参数记录,则继承cdb的参数文件中值,如果PDB_SPFILE$中有记录则使用该值覆盖cdb参数文件值.
删除PDB_SPFILE$验证
SQL> SHOW CON_NAME; CON_NAME ------------------------------ CDB$ROOT SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100 SQL> select con_id,dbid,NAME,OPEN_MODE from v$pdbs; CON_ID DBID NAME OPEN_MODE ---------- ---------- ------------------------------ ---------- 2 4048821679 PDB$SEED READ ONLY 3 3313918585 PDB1 MOUNTED 4 3872456618 PDB2 READ WRITE SQL> alter session set container=pdb2; Session altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100 SQL> alter system set open_cursors=110; System altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 110 SQL> conn / as sysdba Connected. SQL> select value$ from pdb_spfile$ where name='open_cursors'; VALUE$ -------------------------------------------------------------------------------- 110 SQL> delete from pdb_spfile$ where name='open_cursors'; 1 row deleted. SQL> commit; Commit complete. SQL> startup ORACLE instance started. Total System Global Area 597098496 bytes Fixed Size 2291072 bytes Variable Size 272632448 bytes Database Buffers 314572800 bytes Redo Buffers 7602176 bytes Database mounted. Database opened. SQL> select value$ from pdb_spfile$ where name='open_cursors'; no rows selected SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100 SQL> alter session set container=pdb2 ; Session altered. SQL> alter database open; Database altered. SQL> show parameter open_cursors; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ open_cursors integer 100
删除PDB_SPFILE$中相关记录,pdb的参数值会自动继续继承cdb中参数值
总结说明:通过上述的一些列试验证明cdb中参数关系,在cdb中修改,会默认所有pdb均自动继承;如果在pdb中修改值会覆盖cdb参数,而且只对当前pdb生效,并记录在PDB_SPFILE$
发表在 ORACLE 12C
评论关闭
ORACLE 12C ASM 新特性:共享密码文件
在ORACLE 12C之前大家都知道密码文件是存放在?/dbs或者?/database中,如果要修改修改sysdba权限的用户密码时候,会去修改密码文件,而在rac数据库的sys密码文件是存在各个节点中,这个时候修改sysdba权限的密码就需要在两个节点都要做同样的操作,而对于数据库来说本身是只要在一个节点上修改即可,因为密码是记录在user$中,就是因为密码文件非共享且在各个节点中都有,因此需要在各个节点均要执行修改密码命令,确保密码文件被正常修改。因为rac 密码文件非共享的机制存在,导致修改sysdba权限密码繁琐,有些时候甚至有节点忘记修改,导致需要使用密码文件操作数据库的时候不能正常进行,DG传输日志异常等故障。在ORACLE 12C中为了解决这个问题,引入了密码文件可以存入ASM新特性,从而使得密码文件存储在ASM中实现所有节点共享,从而解决该问题.
ASM存储密码文件前提条件 COMPATIBLE.ASM>= 12.1
查询ASM信息
SQL> select * from v$version; BANNER CON_ID -------------------------------------------------------------------------------- ---------- Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0 PL/SQL Release 12.1.0.1.0 - Production 0 CORE 12.1.0.1.0 Production 0 TNS for Linux: Version 12.1.0.1.0 - Production 0 NLSRTL Version 12.1.0.1.0 - Production 0 SQL> select NAME,COMPATIBILITY from v$asm_diskgroup; NAME COMPATIBILITY ------------------------------ ------------------------------------------------------------ DATA 12.1.0.0.0
查询crs中关于db配置
[grid@xifenfei ~]$ srvctl config database -d cdb Database unique name: cdb Database name: cdb Oracle home: /u01/app/oracle/product/12.1/db_1 Oracle user: oracle Spfile: +DATA/cdb/spfilecdb.ora Password file: Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: MANUAL Database instance: cdb Disk Groups: DATA Services:
这里db的password file为空,即表示使用默认值,也就是为$ORACLE_HOME/dbs/orapwxifenfei
创建密码文件存储在ASM中
--创建db新密码文件 [oracle@xifenfei ~]$ orapwd file='+data/CDB/orapwdxifenfei' dbuniquename='cdb' Enter password for SYS: ----输入sys用户密码 --创建asm新密码文件 orapwd file='+data/ASM/orapwasm' asm=y ----asm=y 表示创建的密码文件为asm的 --使用老密码文件创建db/asm新密码文件 orapwd input_file='/oraclegrid/dbs/orapwasm' file='+data/ASM/orapwasm' [asm=y] ----input_file 表示使用老的密码文件创建新的存储在ASM中的密码文件
查看ASM中密码文件
ASMCMD> showversion ASM version : 12.1.0.1.0 ASMCMD> pwd +data/cdb ASMCMD> ls -l orapwdxifenfei Type Redund Striped Time Sys Name PASSWORD UNPROT COARSE MAY 31 19:00:00 N orapwdxifenfei => +DATA/CDB/PASSWORD/pwdcdb.290.816897265
配置crs中password file项
[grid@xifenfei ~]$ srvctl modify database -db cdb -pwfile +data/CDB/orapwdxifenfei
查询crs中关于db配置
[grid@xifenfei ~]$ srvctl config database -d cdb Database unique name: cdb Database name: cdb Oracle home: /u01/app/oracle/product/12.1/db_1 Oracle user: oracle Spfile: +DATA/cdb/spfilecdb.ora Password file: +data/CDB/orapwdxifenfei Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: MANUAL Database instance: cdb Disk Groups: DATA Services:
至此数据库启动使用密码ASM中的密码文件完成,补充说明,该方式配置在ASM中的密码文件,只能是通过crs方式启动db才会生效,如果手工使用sqlplus启动数据库不会使用该密码文件,还是使用默认密码文件。这里也就提醒大家操作规范:在RAC环境(包含单节点的GI环境)中,对数据库的启动关闭操作强烈建议使用crs相关命令来完成,而不推荐使用sqlplus命令