冥净的博客

新版本的达梦数据库中使用之前的语句查看版本信息后面的id_code显示不便于查看版本号。

2、确保网络畅通，即数据库1所在的网络能够连接到数据库2端口。如果创建双向dblink则需要开通两端数据库端口，如果单项dblink则只需要开通源端到被访问的目标端数据库端口即可。如果dblink创建使用物理IP则只需要开通到集群任意一个节点的物理IP端口即可，如果使用scanIP还需要开通俩个vip端口，不然仅通过scanIP dblink无法飘到虚拟ip的端口。3、创建Dblink，这里有两种方法：一种是直接修改tnsnames.ora文件，一个是在创建Dblink时直接加数据库连接。

由于对跑批涉及的表在周末6点前进行了清数，Oracle周末自动收集统计信息的时间为早上6点，此时的表内数据量为0，导致对该表的执行计划发生了变化。因此在下午跑批过程中走的错误的执行计划，导致数据库中出现大量的排序操作或者使用临时表来存储中间结果，从而消耗大量的临时表空间，最终出现临时表空间不足的报错。

分析原因由于某业务中台应用程序存在一些性能不佳的SQL语句，未创建索引，执行效率极低，且在问题发生时段内频繁调用（6000余次/分钟），导致应用连接数据库的会话数暴增，服务器内存被耗尽并HANG死。解决方案发现数据库服务器内存被耗尽后，临时调整了操作系统内存大页参数，设置上限值（官方手册中该参数默认关闭），并重启服务器使参数生效，避免应用会话数无限增加而耗尽内存。

【代码】oracle insert操作分批量提交。

查看监听状态发现监听确实没有启动，start监听却出现TNS-01106: Listener using listener name LISTENER has already been started。仔细查看刚刚监听状态下面报有TNS-01189: The listener could not authenticate the user监听无法验证用户。修改了hosts文件中的主机名和ip信息再次启动监听成功。测试环境无法连接数据库，怀疑监听没有启动查看监听状态。通过ps查看，发现并没有监听进程。

查看自己两边磁盘UUID是否相同(for i in 后面为磁盘sd后字母名)检查所加diskgroup名称，diskstring形式。ASM磁盘rebalance后检看ASM磁盘空间情况。ASM磁盘rebalance后检查数据库集群状态。先通过lsblk来查看集群两端磁盘是否扩容成功。mpath查看自己两边磁盘UUID是否相同。两边编辑绑定文件后，依次执行以下命令。查看ASM磁盘rebalance情况。执行后检查两边的磁盘权限属组情况。添加磁盘到DATA磁盘组中。

进行move操作时，查询 v$locked_objects视图，可以看到表上加了 exclusive lock锁，所以切勿在业务时间段进行move表操作。在对表进行move前要注意，move操作时如果不指定表空间，则在原表空间移动数据块，在这个表空间中需要至少额外一倍该表大小的空间。数据库经常性的通过delete来清数，导致数据库出现高水位，通过对表move或者行迁移来降低高水位。对表进行move操作，move到原本表空间内。索引创建完后并行度调至回1（即不适用并行）重建索引开启4个并行。

如果没法第一时间备份情况下，先将数据库文件拷贝到本地，先将asm中日志文件清理，恢复数据库业务使用，之后再将本地拷贝出来的日志文件，重新拷贝回asm磁盘组中，再进行备份。备份问题解决后，将这些日志重新拷贝回 ASM 后再备份时注意日志磁盘空间使用情况，防止再次出现档日志磁盘组空间不足。备份出现问题，ASM 中归档日志磁盘组空间不足，暂时无法扩容，数据库不可用。备份问题解决后，将这些日志重新拷贝回 ASM 后再备份。可以备份情况下，先备份之后直接清理日志文件。先将归档日志文件从ASM磁盘中拷贝到本地。

可见，大表大部分都是AUD和WRH开头的AWR基表，AUD$使用SYSTEM表空间，AWR的基表使用SYSAUX表空间。2.查看下使用SYSTEM和SYSAUX表空间的比较大的表。

检查数据库归档日志生成情况。删除1天前的归档文件。

客户存在一个环境数据库的nas存储掉了,重新把nas磁盘挂回来后，链接不到数据库,数据库abort也停不下来，abort后日志也没有输出，startup就卡死了。因为服务器又重启过，所有上面也o不存在racle的进程，重新挂载回来的nas盘上的目录权限也检查了都没有问题。可是就是每次sqlplus链接不到数据库，无法对数据库进行任何操作，alter日志也始终没有任何信息。此时umount盘都不行，显示占用繁忙，fuser目录之后再umount可以。之后大佬指点重新挂载nas盘，并且挂载时添加参数。

这是由于操作系统缺少fuser命令导致的。

【代码】清理审计和监听垃圾文件脚本。

4.重新登录回Oracle用户再重启数据库。1.两个节点都修改limits.conf。–查看当前 locked memory值。–查看当前节点数据库有没有DML操作。7.节点1于节点2相同操作。2.变更时间.登录节点2。3.检查后关闭数据库。6.查看大页使用情况。

看的出来跑批执行时间在7点40分左右，每次执行10分钟以上，8点会有大量的联机任务进来，所以为了防止跑批的行锁影响到联机的sql任务，最好将批量任务再提前一些到7点这个时间段，防止影响联机业务。12月3号9点时分，业务发现在8点的时间段出现了大量的业务排队等待，等待时间接近30分钟，且该时段的业务为联机业务肥批量业务，需要协助排查问题原因。可以看到在该时间段一共执行156次update的sql，平均用时竟6s之久，联机业务平均等待时间6s严重影响业务，等待的事件是行锁。再查看联机业务的历史执行时间。

测试库上午使用一直正常，到中午时突然出现了报错，在没有做什么变更的情况下，该报错原因为​多是是由于超过连接最大值导致无法登录。

现为测试环境，机器有且仅有两个网卡存在，需求修改Public IP/VIP/Private IP/Scan IP，把Public IP/VIP/Scan IP的网段改为Private IP的网段，Private IP于Public IP网段互换。

创建一个新的表空间并创建新的用户，指定新表空间为新用户的默认表空间。这时连shutdown immediate关库都关不掉了。只能用 shutdown abort 关闭数据库了。因为数据文件丢失启动数据库只能起到mount状态。然后先 offline 这个数据文件再打开数据库。接下来创建给表空间添加新的数据文件并插入数据。再次插入数据显示已经找不到dbf数据库文件了。zzw用户已经创建过，这里修改其默认表空间。recover 恢复数据文件。查看数据文件是否onilne。online 数据文件。

自己在测试环境想要使自己的Oracle数据库用户使用简单的密码方便测试，结果指定密码的密码验证失败。取消Oracle数据库密码复杂度查询。