Sebastien23的博客

登录成功后备份参数文件，并扩容数据库最大连接数，重启数据库。需要扩容数据库的processes参数。现象：数据库进程仍在，但无法正常连接。重启数据库后，应当可以正常连接了。如果多次尝试登录数据库都报错。

🐬 创建只有一个分区的分区表, 通过分区交换将原表变成分区表，然后分裂分区，最后再重命名表。🐬 Oracle支持将非分区表交换为分区表的一个分区/子分区。🐬 分区交换过程中，source表的数据会移动到target表，target表的数据则会移动到source表。

为源表tab_oasis"DT" DATE,根据原表定义创建分区表，字段保持一致。--源表：TAB_OASIS，中间表：TAB_REDEFBEGINEND;BEGINEND;COUNT(*)----------10COUNT(*)----------10可以看到，重定义过程就好像交换了源表和中间表的表结构，因此变更前最好对源表做一次备份。

-以一个年代划分分区，分区列为DT。

【代码】Oracle数据库ORA-01658报错处理。

故障切换后，需要移除旧的DG Broker配置。由于是故障切换，DG Broker配置信息没有更新，因此不能直接通过DGMGRL命令来移除旧的配置信息。主库发生故障无法在短时间内恢复时，需要执行主备切换。此时由于DG Broker无法连接到主库，故不能通过Broker切换，只能手动在备库进行切主。参数，并清理相关配置文件，然后重新开启该参数即可。

【代码】【SQL脚本】梳理Oracle表空间详细使用情况。

排查占用UNDO段未释放的SQL。

⭐️：Oracle 19.18升级到19.22，并安装ONE-OFF PATCH 35818395。⭐️：RHEL Linux, Oracle ADG，一主库一物理备库。⭐️。

⭐️ Oracle数据库版本为19.18。

定义中添加了大量CASE WHEN判断和一个子查询，导致原来的执行计划A根本跑不出来，所以即使在已经绑定了执行计划的情况下，也走了一个新生成的执行计划B。是的，那就重启一下吧。上周周末的一天清晨，应用的同事给我打了个电话，说周五晚上有个跑批的SQL，在周六凌晨卡住跑不动了，一直卡了四个多小时都跑过不去。这时，我仔细对比了一下两个执行计划，发现好的执行计划A在访问前面提到的那个分区表时，走了某个索引。果然不出所料，这个SQL最近俩月的的执行计划都是同一个执行计划A，但是在昨儿晚上突然变成了执行计划B。

READER24用户对表 RDR_NPC 执行 SELECT FOR UPDATE 操作后，既不提交也不回滚。READER24退出会话后，APPUSER1的更新和删除操作才能继续执行。READER24提交会话后，APPUSER1的更新和删除操作也能继续执行。只读用户READER24执行 UPDATE 报错后，退出会话。检查发现APPUSER1会话有行锁等待。

这种用户对自己默认表空间没有使用权限的现象并不常见。给USER1授予TBS1的表空间权限后，USER2对表USER1.T1执行INSERT操作不再报错ORA-01950。：ORA-01950报错不一定是执行SQL的用户对表空间无权限，也可能是表的owner自己没有权限。授予表空间权限后，USER2可以在USER1下建表，但是INSERT还是会报错ORA-01950。TBS1是用户USER1的默认表空间，TBS2是用户USER2的默认表空间。用户USER2对表USER1.T1本身有DML权限。

随后要求硬件厂商对数据库服务器的存储进行了一次全面检查，最终发现服务器的磁盘阵列卡的某个巡检软件17号运行异常，占用了200多个磁盘通道一直到20号，导致数据库在跑批数据量大时产生IO等待。硬件监控发现跑批数据量大的时候有IO wait产生，但是没有规律可寻。检查监控发现当天上午7:30和10:00数据库负载有明显升高的现象，不过并没有达到系统上限。但联系硬件同事查看磁盘监控时，反馈磁盘IO正常，没有压力和瓶颈问题。硬件厂商对磁盘阵列软件进行修复后，应用反馈跑批速度恢复正常，至此问题解决。

📖 更多的数据库内存组件配置请参考：https://gottdeskrieges.blog.youkuaiyun.com/article/details/130296763。：必须先扩容数据库SGA内存并重启数据库再执行huge.sh脚本，不然计算出来的大页数量不对！以root用户运行Oracle官方的。脚本给出的sed命令来修改大页参数。重启操作系统使得大页参数生效。

表是审计功能的底层表，如果需要对审计数据进行删除,只需要对该表进行清理既可,其他视图里的数据都是从。模式下，操作系统的审计日志中记录的内容非常有限，主要的审计日志都存储在数据库内部视图中。是静态参数，修改后必须重启数据库才能生效（

根据对应时间段（REDO日志暴增、数据块变化量大）生成AWR报告，获取TOP Gets、TOP Execution中靠前的DML SQL语句，一般就是罪魁祸首。补充（附加）日志的开启会导致日志的生成量明显增加。附加日志通常是为了部署CDC应用而开启的。替换为上一步中查出来数据块变化量大的表名。BETWEEN和AND之间的时间跨度为一小时。BETWEEN和AND之间修改为对应REDO日志暴涨的时间段，跨度为一小时。也可以使用下面的SQL来定位（可能执行会比较耗时）。

授予PUBLIC缺失的包执行权限，并重新编译失效对象。最后重新安装Datapatch数据补丁即可。最后四行的结果不是SUCCESS。检查PUBLIC对包。

【代码】Oracle自动统计信息收集问题排查脚本。

【SQL脚本】获取Oracle SQL中使用绑定变量的值。

查看开启和关闭的自动收集任务（

【代码】检查与批量清理Oracle用户会话。

其中涉及的数据库后台进程CLnn负责清理已终止的进程和会话，是主清理进程CLMN下的辅助进程。PMON进程负责监控后台进程的终止，并通知CLMN进程进行清理。DG备库中PMON进程在做清理时找不到undo temp的指针，CLnn进程异常引发实例Crash。补丁包下载：https://updates.oracle.com/download/35818395.html。：应用one-off patch 35818395来解决该Bug。可以先在两个备库打补丁，主库在观察一个月之后再打补丁。

【Shell脚本】生成Oracle数据库内存配置减半的参数文件。

确认JServer JAVA Virtual Machine为有效即可。执行Deploy来京数据库升级。

对于user1在user2模式下创建的表，如果user1需要查询或DML权限，可以通过单独授予对象权限来实现、也可以通过授予。权限后，user1可以在user2模式下创建表，但是user1对创建的表。可以看到存储过程、函数、包共用一套权限，建表权限默认包含建索引权限。对于user1在user2模式下创建的表，

测试环境有套Oracle数据库的/oracle目录满了，检查发现有部分表空间文件、日志文件和控制文件生成在了/oracle目录下，需要对这部分数据库文件进行迁移。

应急处置时手动拉起DG即可。处理办法：调整隐藏参数。

用户登录失败的原因通常是由于修改用户密码后未及时更新JDBC连接池中配置的登录口令，导致应用在连接数据库失败后通过连接池不断重复发起连接请求，导致通过正确密码连接的用户登录变慢。该用户存在大量并发的、失败的数据库连接登录请求，导致触发了Bug 19637855、Bug 19867671或者Bug 24469107。尤其针对有Libary cache lock等待事件的用户和主机。产生问题的用户可以正常登录，但是无论是远程登陆还是本地登录都很慢，至少等待一分钟以上。产生问题的用户近期可能修改过密码。

的时，执行用户必须是JOB OWNER或者对JOB具有ALTER权限。也可以对用户授予CREATE ANY JOB或者MANAGE SCHEDULER权限（不推荐）。参数时，用户必须具有MANAGE SCHEDULER权限，否则会报ORA-27486权限不足。该普通用户有CREATE JOB的权限。

然后重新运行runInstaller即可。🦆操作系统版本：CentOS 8.8。上述报错涉及到操作系统兼容性问题。

表示undo数据保留的最短时间（秒），如果undo空间不足，undo表空间会自动扩展（需要开启autoextend）。值为AUTO或者null，表示启用了自动undo管理。

过了一会儿数据库又宕机了，检查发现是生成了大量trace文件占满了oracle目录。可能是因为没有设置10513事件，大量事务恢复失败的日志不停地刷到trace文件中。：我自己实际操作过程中没有设置10513事件，可能会导致ORA-600 [4137]报错，后面会提到。发现控制文件和数据文件头中记录的SCN是一致的，考虑重建UNDO表空间即可。：完成NBU带库恢复后，测试库打开后几分钟就会自己宕机挂掉。不能删除的原因是UNDOTBS1还有未下线的段，状态为。不能有报错，否则要单独对报错进行处理。

的比值是否超过10%，可以大致估算是否会触发统计信息自动收集。表示锁定的统计信息类型（data/cache/all），是指DML操作导致表的行记录被修改/增删的比例。表示被DROP过的分区和子分区的段数。通过计算表被插入、更新和删除的总行数与。表示是否被TRUNCATE过，插入/更新/删除的次数，表示统计信息是否过期。

问题数据库版本为11g，没有升级到12c的计划。因此这里我们采用workaround，即调大open_links，将其调大到100。该参数调整后需要重启数据库。ORA-00600报错一般与Oracle数据库内部Bug有关。注意第一行arguments后面三个方括号中的数字与信息，可用于确定相关的数据库Bug。官方推荐了两种应对办法。一种是workaround办法，另一种是升级数据库到版本12.2.0.1。经确认，报错的应用确实使用了大量DBLINK，与该BUG描述的触发场景一致。

⭐️。

怀疑是当前备库曾经切换为SNAPSHOT模式，期间的某些操作导致切回物理备库模式时，切到了与主库不同的化身（INCARNATION）。DG备库MRP日志应用进程停止，重启进程后马上又会挂掉。可以看到，当前（CURRENT）两者的化身不同。最后打开备库，观察同步状态即可。

【代码】行锁导致的SQL阻塞问题分析处理。

计算合适的大页数量（发现操作系统未开启大页。

如果上面重启MRP进程后还是一直没有恢复正常同步，很可能是由于主库和其他备库的归档日志被清理了，导致获取不到部分归档日志，这种情况下还需要额外进行增量备份恢复。上面这种情况就是归档日志中有部分序列从其他所有库都获取不到了，需要做一次增量备份恢复。