标签云
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,773)
- DB2 (22)
- MySQL (77)
- Oracle (1,612)
- 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备份恢复 (593)
- Oracle安装升级 (98)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (32)
- pdu工具 (6)
- PostgreSQL恢复 (10)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- pg_wal中文件的名称中的logseq和实际文件中的logseq不匹配
- 由于空间满导致PostgreSQL数据库异常处理
- 一次非常幸运的ORA-600 16703(tab$被清空)故障恢复
- Oracle 19c 202507补丁(RUs+OJVM)-19.28
- 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库的案例
分类目录归档:Oracle
授权用户访问数据字典三种方式
在很多时候,希望给用户最小的权限,让其访问系统数据字典,检查数据库的运行状态。这种事情在乙方的工作中非常常见。下面介绍三种方法处理这个问题
0.select any table权限
这里说明select any table不能直接访问数据字典
SQL> conn / as sysdba Connected. SQL> create user xff_any identified by xifenfei; User created. SQL> grant connect,select any table to xff_any; Grant succeeded. SQL> conn xff_any/xifenfei Connected. SQL> select count(*) from dba_users; select count(*) from dba_users * ERROR at line 1: ORA-00942: table or view does not exist SQL> select count(*) from chf.t_xff; COUNT(*) ---------- 2770
select any table默认情况下,只能访问业务的表,但是不能访问数据字典的数据。所以单纯的这个属性不能满足需求。
1.SELECT ANY DICTIONARY权限
SQL> conn / as sysdba Connected. SQL> create user xff_DICTIONARY identified by xifenfei; User created. SQL> grant connect to xff_DICTIONARY; Grant succeeded. SQL> conn xff_DICTIONARY/xifenfei Connected. SQL> select count(*) from dba_users; select count(*) from dba_users * ERROR at line 1: ORA-00942: table or view does not exist SQL> conn / as sysdba Connected. SQL> grant SELECT ANY DICTIONARY to xff_DICTIONARY; Grant succeeded. SQL> conn xff_DICTIONARY/xifenfei Connected. SQL> select count(*) from dba_users; COUNT(*) ---------- 32 SQL> select count(*) from chf.t_xff; select count(*) from chf.t_xff * ERROR at line 1: ORA-00942: table or view does not exist
这里可以看出SELECT ANY DICTIONARY权限只能访问数据字典,不能访问业务的表,访问业务的表需要另外授权
2.SELECT_CATALOG_ROLE角色
SQL> conn / as sysdba Connected. SQL> create user xff_CATALOG identified by xifenfei; User created. SQL> grant connect,SELECT_CATALOG_ROLE to xff_CATALOG; Grant succeeded. SQL> conn xff_CATALOG/xifenfei Connected. SQL> select count(*) from dba_users; COUNT(*) ---------- 33 SQL> select count(*) from chf.t_xff; select count(*) from chf.t_xff * ERROR at line 1: ORA-00942: table or view does not exist
这里可以看出SELECT_CATALOG_ROLE权限只能访问数据字典,不能访问业务的表,访问业务的表需要另外授权
3.O7_DICTIONARY_ACCESSIBILITY参数
SQL> conn / as sysdba Connected. SQL> create user xff_O7 identified by xifenfei; User created. SQL> grant connect to xff_o7; Grant succeeded. SQL> alter system set O7_DICTIONARY_ACCESSIBILITY=true; alter system set O7_DICTIONARY_ACCESSIBILITY=true * ERROR at line 1: ORA-02095: specified initialization parameter cannot be modified SQL> alter system set O7_DICTIONARY_ACCESSIBILITY=true scope=spfile; System altered. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 368263168 bytes Fixed Size 1345016 bytes Variable Size 306186760 bytes Database Buffers 54525952 bytes Redo Buffers 6205440 bytes Database mounted. Database opened. SQL> conn xff_o7/xifenfei Connected. SQL> select count(*) from dba_users; COUNT(*) ---------- 34
这里通过O7_DICTIONARY_ACCESSIBILITY和SELECT ANY TABLE权限,实现访问业务数据和数据字典
发表在 Oracle
评论关闭
跟踪ORACLE非当前会话
使用oradebug
session 1 --查询出需要跟踪会话v$process.pid session 2 SQL> oradebug SETORAPID 15 Unix process pid: 14851, image: oracle@xifenfei (TNS V1-V3) SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 4 Statement processed. --执行session 1 session 1 SQL> oradebug EVENT 10046 trace name context off Statement processed. SQL> oradebug TRACEFILE_NAME /u01/oracle/admin/xifenfei/udump/xff_ora_14851.trc
使用dbms_system.set_sql_trace_in_session
session 1 --查询出需要跟踪会话的sid,SERIAL# session 2 SQL> exec dbms_system.set_sql_trace_in_session(12,130,true); PL/SQL procedure successfully completed. --session 1执行sql session2关闭跟踪 SQL> exec dbms_system.set_sql_trace_in_session(12,130,false); PL/SQL procedure successfully completed. --通过session 1找出trace文件
发表在 Oracle
评论关闭
ORA-01052: required destination LOG_ARCHIVE_DUPLEX_DEST is not specified
SCN说明
1、Oracle的SCN在每秒16384次commit的情况下可以维持534年,每秒16384次commit是Oracle早先认为的任何系统的极限commit强度;
2、Oracle里SCN的起点是1988年1月1日;
3、_minimum_giga_scn=n的含义是把SCN往前推进到nG,但请注意,只有在SCN小于nG的时候才会用到这个隐含参数,反之则Oracle会置这个隐含参数于不顾。
求模拟_minimum_giga_scn值
这里通过时间差,大概的模拟_minimum_giga_scn小于当前时间和1988年1月1日的scn最大值(300>290)
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')from dual; TO_CHAR(SYSDATE,'YYYY-MM-DDHH24:MI:SS' -------------------------------------- 2012-03-18 04:27:50 SQL> select months_between(sysdate,to_date('19880101','yyyymmdd')) from dual; MONTHS_BETWEEN(SYSDATE,TO_DATE('19880101','YYYYMMDD')) ------------------------------------------------------ 290.55443 SQL> select 16384*60*60*24*31*300/(1024*1024*1024) SCN from dual; SCN ---------- 12260.7422
启动数据库测试
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. -------------------------------- *._minimum_giga_scn=12260 -------------------------------- SQL> startup pfile='/tmp/pfile' ORACLE instance started. Total System Global Area 236000356 bytes Fixed Size 451684 bytes Variable Size 201326592 bytes Database Buffers 33554432 bytes Redo Buffers 667648 bytes Database mounted. ORA-01052: required destination LOG_ARCHIVE_DUPLEX_DEST is not specified
分析ORA-01052
SQL> !oerr ora 1052 01052, 00000, "required destination LOG_ARCHIVE_DUPLEX_DEST is not specified" // *Cause: A valid destination for parameter LOG_ARCHIVE_DUPLEX_DEST was not // specified when parameter LOG_ARCHIVE_MIN_SUCCEED_DEST was set to // two. // *Action: Either specify a value for parameter LOG_ARCHIVE_DUPLEX_DEST, or // reduce the value for parameter LOG_ARCHIVE_MIN_SUCCEED_DEST to one. SQL> show parameter LOG_ARCHIVE_DUPLEX_DEST; NAME TYPE VALUE ------------------------------------ ---------- ------------------------------ log_archive_duplex_dest string SQL> show parameter LOG_ARCHIVE_MIN_SUCCEED_DEST NAME TYPE VALUE ------------------------------------ ---------- ------------------------------ log_archive_min_succeed_dest integer 1
这里可以看出,不是以为我上面的两个参数设置错误导致ORA-01052,而是因为推进scn过大导致ORA-01052的错误
减小_minimum_giga_scn测试
这里选择_minimum_giga_scn小于当前时间和1988年1月1日的scn最大值(280<290)
SQL> select 16384*60*60*24*31*280/(1024*1024*1024) SCN from dual; SCN ———- 11443.3594 SQL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. —————————– *._minimum_giga_scn=11443 —————————– SQL> startup pfile=’/tmp/pfile’ ORACLE instance started. Total System Global Area 236000356 bytes Fixed Size 451684 bytes Variable Size 201326592 bytes Database Buffers 33554432 bytes Redo Buffers 667648 bytes Database mounted. Database opened. SQL> select to_char(dbms_flashback.get_system_change_number(), 2 ’9999999999999999′) from dual; TO_CHAR(DBMS_FLASHBACK.GET_SYSTEM_ ———————————- 12286827692251 SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual; DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER()/(1024*1024*1024) ———————————————————- 11443
通过试验可以发现,在我们的数据库遇到异常,需要恢复通过推进scn来恢复的时候,不是推进的越大越好;如果推进的太大可能导致ORA-01052错误,一般建议是比当前不一致的scn稍微大一点
参考:http://www.dbsnake.net/two-scn-internal-points.html