Oracle 12C wait ‘library cache lock’ after change password even set 28401 event 案例

主要是在11g引入的安全特性延迟密码认证在3-10秒,在延迟期间以X模式持有row cache lock防止同一用户的并发失败尝试。通常是配置28401 event禁用延迟认证特性,但这也不是“万能药”,像这次的案例。 除了密码延迟认证,PASSWORD_LIFE_TIME和FAILED_LOGIN_ATTEMPTS 也是用户的警惕的地方。

, , ,

Oracle 19c新特性: EXPDP 参数TTS_CLOSURE_CHECK估算Transportable Tablespace时间

TTS(Transportable Tablespace)在大型数据库迁移方案看较常见,复制数据文件实现了在线,但是导出元数据阶段需要把表空间改为只读,写业务要中断,那就存在一个问题,导出metadata元数据需要多少时间?有没有不可预见的问题?19c DATAPUMP引入新特性TTS_CLOSURE_CHECK为此而生

,

High wait event ‘row cache mutex’ in 12cR2、19c

In Oracle 12.2.0.1.0 (12cR2), “row cache mutex” replaced 12.1.0.2.0 (12cR1) and 11g “latch: row cache objects”, similar to “latch: library cache” substitution by “library cache: mutex X” in the previous release. High waits on “row cache mutex” when looking up user or role information in user row cache (dc_users)

,

Oracle 11g 升级 12c 、19c后改变 database trigger fail with ORA-01031

无论出于安全、特性、性能、支持周期都需要考虑升级数据库,但是也会导致有些功能改变而影响软件使用或管理方式,升级后经验格外重要,因为oracle官方提供的功能无法模拟各行业生产环境中所有的应用场景, 尤其是从最近要面临的11g升级19c大版本升级,防止踩雷,像wm_concat 在新版本不支持一样。

, ,

Troubleshooting Oracle 19c RAC db crash with ORA-00600 [kcbbxsv_nwp]

ORA-00600: internal error code, arguments: [kcbbxsv_nwp], [], [], [], [], [], [], [], [], [], [], []
kge_experr : Found error ORA-600 not in expected list.
kge_experr: Dumping error frames [top = 1 : barrier top = 0]
kge_experr : [0] : Error = ORA-600 :
Call stack = ksedsts()+426<-kge_snap_callstack()+77<-kgeadse()+557<-kgerinv_internal()+44 <-kgerinv()+40<-kserin()+180<-kcbbxsv()+17478<-kcbb_coalesce_int()+326<-kcbb_coalesce()+438< -kcbbwthc()+817<-kcbbdrv()+8765<-ksb_act_run_int()+117<-ksb_act_run()+130<-ksbcti()+18

升级Oracle 19c经验: TTS时ORA-39083和ORA-00942案例

上周在使用TTS传输表空间从11.2.0.4到19C, 在最后impdp metadata的环节提示ora-942 结果提示有大量索引没有创建成功,但是查看报错的表实际是存在的, 后来发现这是一个收权问题导致的。后分析这种场景是发生在如一开始给了一个用户如create ANY table/index的系统权限或者dba 角色或是on object上的权限,后来创建了跨SCHEMA的index(indexes and tables differenct owners)或FK 约束时,再后来安全整改收回大权限,就导致了这个问题。

, ,

How to disable DRM? Oracle 10G, 11G, 12C-19C

DRM is driven by the following
1.) _gc_affinity_time = Time in minutes at which statistics will be evaluated (default = 10 mins)
2.) _gc_affinity_limit = # of times a node accesses a file/object (default = 50)
3.) _gc_affinity_minimum = minimum # of times per minute a file/object is accessed before affinity kicks in
(default = 600 per minute per cpu )
4.) _lm_drm_disable = LEVEL disable drm in different level( default=0 )

升级Oracle 19c经验: TTS 在使用datapump导matadata时EXCLUDE=STATISTICS 不启作用

在使用TTS迁移一个8T 的11.2.04到19c PDB时,发现expdp和imdp元数据过程中statistic占用了约1个多小时的时间, 但是我检查了实时步骤中确实有写exclude=statistics,猜测是参数没启作用,不能忍. 结果发现这是一个预期行为

,

Oracle 12c 19c Automatic terminal/kill session feature

数据库会话同样会占用数据库资源,如客户端异常断开在客户端成为一个dead session会永远存在,如果客户端没有断开也没有活动就是一个idle session, 如果这个idle session做了一些修改未提交,然后下班或去吃饭、上WC、开会等,这时就会堵塞其他人对相同的数据做修改,这类会话可以叫做idle blocker session. 在自治数据库中这些session 都可以被释放或者kill / teminal 终结掉,下面对不同的session如何被释放

Oracle 11g 12c 18c 19c .. IMPDP Always Creates Indexes with Degree 1

From 12.2, DataPump import (impdp) will always use non-parallel index creation during import overriding parameter ‘parallel’ in command line or parameter file.

, ,

密码保护:特殊恢复: Oracle 19c REDO和UNDO 文件被删除

无法提供摘要。这是一篇受保护的文章。

, ,

BBED simulates and fixes ORA-08102 error (Oracle 19c) (二)

方法一使用了bbed修改 index key的方法, 因为表列上只有这一个索引,所以只改一个索引就可以。这里还使用相同的方法模拟ora-8102,使用第二种方法,删除bootstrap$中的index I_OBJ4 记录解决。

,

BBED simulates and fixes ORA-08102 error (Oracle 19c)

Sometimes due to sudden power failure and other reasons, the database data dictionary is inconsistent, such as hits ora-8102, the indexes key and the table key value does not match, often delete the index, rebuild the index can be resolved, but if the object_id <60 bootstrap$ internal The index is damaged, and the normal situation needs to be backed up and restored, because some of the indexes in these bootstrap $ cannot be rebuilt by setting event 38003

,

Oracle数据库许可(License)

Oracle产品可从Oracle网站免费下载。但是,在使用它之前,您需要同意Oracle Technology Network(OTN)开发人员许可条款。最近几年虚拟化、云化环境的普及,Oracle的license许可有些疑惑,在这里特意整理一下。Oracle文档中关于此主题的信息确实很少,稍不注意可能会带了百万级的费用消耗, 前提是你有严格对待ORACLE的软件许可,当然还是以Oracle合同中指定条款为主。

DB Time 去哪了? Oracle 12C AWR 增加了on cpu runqueue

是否遇到过在分析AWR报告时,明明AAS很高,但从Top 10 Foreground Events by Total Wait Time 上看top event使用的百分比加起来离100%很远? 那DB TIME去哪了?下面我附一个11G(11.2.0.4 RAC on AIX) AWR 案例,这个问题在12c的AWR中提供了TOP EVENT。

,

Oracle 20c新特性: dbms_xplan.display_awr 增加了谓词信息

执行计划中的谓词信息非常的重要,有助于我们判断是否进行了隐式转换,为什么没有使用索引等, 使用dbms_xplan.display_cursor可以从shared_pool中取到sq cursor的谓词,但是在20c之前dbms_xplan.display_AWR 在之前的版本中并不能, 但是Oracle社区的投票和诸多人的推动下,终于在oracle 20c所谓词信息也在dbms_xplan.display_AWR中显示

,

Enable DDL logging in Oracle databaase (安全审计)

Oracle database use DDL statements to define structures such as tables to store data and functions to store code. By default Oracle database does not log any DDL operations performed by any user.When someone do some destructive DDL in DB, we often need the DDL log..In this article I will only record the method of using Oracle Database Lifecycle Management Pack( Enable_ddl_logging)

Oracle 12c Alert log show ” ADVISORY: Please collect redo for investigation of ORA-8103″ frequently

叕一个oracle 12c频繁生成日志文件的问题,最近一套12.2的RAC突然又文件系统告警,生成了大量的trace文件,db alert log也在不停的显示如下内容:
ADVISORY: Please collect redo for investigation of ORA-8103. Use command:
ALTER SYSTEM DUMP REDO scn min 1 scn max 16716635042430 dba min 32 2094058 dba max 32 2094058;

Troubleshooting ORA-01578 ORA-01110 ORA-26040 NOLOGGING corrupted block

The following errors have recently occurred in our database( Oracle 19c RAC):
ORA-01578: ORACLE data block corrupted (file # xxx, block # yyyyy)
ORA-01110: data file xxx: ‘xxxxxxxxxxxxxxxxx.dbf’
ORA-26040: Data block was loaded using the NOLOGGING option

, , , ,

Oracle 哪些进程可以KILL不会导致实例重启?

oracle后台进程当出现问题时,有些进程kill会导致实例立即重启,像smon, pmon,ckpt.. , 而有些进程kill并不会影响实例可用性, 甚至会立即做进程级重启从db alert log可以观测到,如mmon,rec,jnnn, pnnn等, 前两天看到Poder在其BLOG分享v$process的基表X$KSUPR中中有记录哪些是oracle的致命进程,在X$KSUPR.KSUPRFLG第3位, 下面我做个测试, kill 点X$KSUPR.KSUPRFLG第3位都不为1的进程。