标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,884)
- DB2 (22)
- MySQL (82)
- Oracle (1,709)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (73)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录19c ASM磁盘掉线触发ORA-59048故障处理
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
分类目录归档:数据库
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命令

加我微信(17813235971)
加我QQ(107644445)

