在升级MySQL版本到8.0的过程中，需要关注sql_mode参数默认值的变化，8.0版本sql_mode不支持 NO_AUTO_CREATE_USER，要避免配置的sql_mode中带有 NO_AUTO_CREATE_USER ■ 57版本原来配置 show variables like '%sql_mode%'; STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE…
最近遇见一个虚机老库11g，主机CPU居高不下，有时甚至无法登录，无法快速建立数据连接。 分析发现较多的应用SQL存在问题，同时发现数据库配置方面也存在问题，分析排查alertlog日志，发现没有配置大内存页。 更多关于大内存页的信息可在本站搜索"大内存页"。 以下是本次操作调整的记录，留作参考。 如下是上次启动的日志提示： Wed Sep 29 14:31:01 2021 Starting ORACLE instance (normal) ************************ La…
19c示例数据表脚本位于： $ORACLE_HOME/rdbms/admin/utlsampl.sql 修改其中的连接语句"CONNECT SCOTT/tiger"为合适的db即可执行创建，如： CONNECT SCOTT/tiger@127.0.0.1:1521/pdb1 现将完整的脚本记录于此，以供其他版本数据库参考。 Rem Copyright (c) 1990, 2017, Oracle and/or its affiliates. Rem All rights reserved. Re…
在后期打patch时常见的一个错误是： Prerequisite check "CheckActiveFilesAndExecutables" failed. 如果在服务端有相关的进程在运行，从而占用可执行文件或运行库，会导致升级时无法更新相应的文件，从而升级失败，报出如上错误。 一般是很容易通过fuser、lsof查出相关的进程的，但有一个情形是无法查出来，只能用fuser查看指定的运行库如libclntsh.so来确定是否占用运行库，如下例。 /u01/app/oracle/product/…
在一次adg构建过程中提示如下报错： [oracle@adg1:0 ~]$ rman target sys/"passwd#"@TESTDB_DGSRC_TNS auxiliary sys/"passwd#"@TESTDB_DGTAR_TNS Recovery Manager: Release 19.0.0.0.0 - Production on Wed Jul 21 21:47:25 2021 Version 19.8.0.0.0 Copyright (c) 1982, 2019, Oracle and/or i…
(接上文) https://likingzi.com/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ https://likingzi.com/2021/06/10/大量事务并发回滚彻底堵塞数据库2/ https://likingzi.com/2021/06/11/大量事务并发回滚彻底堵塞数据库3/ 根据oratop的top等待事件排名，包括累积排名和实时排名，这个"wait for a undo record"已经成为了目标等待事件，是否它阻塞了正常的前滚事务呢？ 根据MOS的搜索结…
(接上文) https://likingzi.com/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ https://likingzi.com/2021/06/10/大量事务并发回滚彻底堵塞数据库2/ 在后续的故障定位时，有人根据如下日志，认为是归档空间满，导致了数据库挂死。 实际不然，这个FAL报错，只是到DG的归档由于其他原因导致了报错，日志也写在了主库alertlog文件，并非是主库归档失败，对主库并无其他影响，仅仅是写了一个日志而已。事后我的详细排查也印证了这一点，当天中午12:00和18:00分…
(接上文) https://likingzi.com/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ 在数次停库、起库的过程当中，遭遇过部分实例起在其他节点的情况，如下。 srvctl start instance -d jkdb -i jkdb1 发现实例1起在了2号节点 srvctl stop instance -d jkdb -i jkdb1 srvctl start instance -d jkdb -i jkdb3 实例3起在了3号节点 srvctl start instance -d jkdb…
这是一个历时5个多小时的故障处理过程，值得认真记录、反思。 事后详查发现，数据库16:00之前就出现大量锁表情况，16:07运维支撑群有用户反映系统慢，直到反馈系统彻底没法用了。下图显示，实际14:00以后就开始出现了较多的锁表情况。 只是，14:00-16:00期间由于只是后台执行任务的锁表，并未明显影响到客户感知，相关的一线业务还可正常进行。 但是当这些执行失败的定时任务一个接着一个，反复重复执行，从而导致大量锁死时，会怎样呢？这会把整个库搞瘫痪。 相关的等待事件涉及到了大量的row cache lock、gc…
昨天在查看一个adg备库时，偶然发现了一个oracle的大坑，就是审计日志文件(*.aud)过多的问题，在adump目录下竟然有接近500万个aud文件，经查阅资料得知，所有以sysdba用户访问数据库的情况，都会记录一个aud文件在adump目录下，即使audit_trail设置为none，也会记录aud文件。 这样的话，当某些情况频繁以sysdba登录数据库的话，经年累月的定时任务，会导致这个路径下积压大量的aud文件，可想而知，严重情况会导致inode占满，导致OS故障，后果不堪设想。 我们知道默认情况数据库…