文档搬运工-CSDN博客

原创 Oracle RAC中OCR整个磁盘的故障模拟恢复

测试目的：模拟整个CRS盘损坏后，如何处理处理过程：重新创建一个同名的磁盘组给OCR使用。restore OCR信息，重新创建voting file。即可。RDBMS 11.2.0.4参考文档： Linux/Unix 平台，在CRS 磁盘组完全丢失后，如何恢复基于 ASM 的 OCR (Doc ID 2331776.1)步骤1 查看当前集群状态、OCRCHECK 、VOTEDISK2 查看当前的OCR的备份，如有必要，模拟前手工备份一次3 使用DD命令进行模拟破坏4 确认所有..

2022-03-19 11:52:23 2818

原创 ORA-600 [kokasgi1]的模拟与修复-Linux平台下

RDBMS 11.2.0.4 + redhat 6.10在RDBMS 12.2.0.1下测试修改SYS用户为SYSA，重启。发现可以正常重启。修改SYS为SYSA后重启数据库。12.2.0.1不存在更改SYS名称的问题。重启后没有问题。在RDBMS 11.2.0.4下测试，发现修改SYS为SYSA后，重启后，报错。无法启动到OPEN状态。连接到数据库，修改SYS为SYSA。重启数据库，报错。查看进程，进程为9711启动数据库到mount状态...

2022-01-01 11:51:21 1420

原创模拟修改sys用户名及恢复- ORA-600 [kokasgi1]

RDBMS 11.2.0.4 + Windows前提条件，确认，定位到了问题是因为sys账号被修改为别的名字。在Windows安装gdb工具，安装包为Dev-Cpp_5.11_TDM-GCC_4.9.2_Setup.exe安装好的路径如下：模拟修改SYS账号名为SYSA重新启动数据库，报错开始修复查找Oracle.exe的进程id ，这里查询到的oracle进程id为4520 。后面会用到这个进程id启动数据库到mount状态使用gdb命令...

2021-12-31 13:21:30 1583 2

原创 pt-table-checksum-sync学习

- 从库数据，前10个值 ID 1-10 ，后修改成100001 - 100010。-- 从打印的/tmp/pt-table-sync文件中，可以看到把修改后的数据插入到了从库上，随后，在从库上删除掉有问题的数据。--修复，参数print值打印结果，并不真正修复，将结果存放在/tmp/pt-table-sync文件中。-- 可以看到，主库上表记录4194305 ，从库上表记录0。--主库数据，前10个值 ID 1-10 ，-- 修复t1 表 ,打印结果，删除1条记录。--再次检查，表t1正常。

2026-08-14 09:59:09 262

原创 mysql 双1测试

- innodb_flush_log_at_trx_commit =1，耗时18.95 sec。-- innodb_flush_log_at_trx_commit =0，耗时12.20 sec。-- innodb_flush_log_at_trx_commit =2，耗时13.11 sec。--innodb_flush_log_at_trx_commit =1，耗时11.14 sec。--innodb_flush_log_at_trx_commit =0，耗时3.10 sec。

2026-08-05 11:15:10 350

原创 proxySQL 学习

- 创建路由规则 -- https://proxysql.com/documentation/proxysql-read-write-split-howto。--primary变成3308 ，出现的问题，monitor用户的权限问题，innodb-cluster01 未添加到proxysql所在的hosts中。-- 查看端口，默认是6032和6033。

2026-08-04 15:18:03 204

原创 RU 19.32安装

2.1.1.1 OPatch Utility Information (19.31 开始read me中多了个CheckMinimumOPatchVersion)2.1.1.5 Run OPatch System Space Check (略)分别在GI和Oracle Home下执行。--节点1 Opatch冲突检查log。-- 节点1 db log。-- 通过视图查看补丁信息。--节点1 gi log。-- 节点2 log。-- 节点1补丁信息。-- 节点2补丁信息。

2026-07-30 16:10:04 307

原创 Innodb Cluster安装

-查看到的用户，看到多了mysql_innodb_cluster_1、mysql_innodb_cluster_2、mysql_innodb_cluster_3. 格式是mysql_innodb_cluster+ server id。mysql router版本：mysql-router-community-9.7.1-1.el8.x86_64.rpm。这三个软件，是安装在同一台测试机器上。mysql版本：mysql-8.4.10-linux-glibc2.28-x86_64.tar.xz。

2026-07-18 15:20:50 277

原创 MySQL router学习-（MGR+ MySQL Router+innodb Cluster）

-在bootstrap得时候，提示MySQL InnoDB Cluster，这个架构是mgr的，非MySQL InnoDB Cluster，需要安装mysql shell，并创建innodb cluster。-- 测试，通过不同的端口，连接到mysql router，会实际上连接到不同的节点上。-- info ：mysql版本，8.4 三个节点的mgr ，单主模式。-- 使用生成的脚本，启动mysql router ，启动后，可以在os上看到相关的进程。-- 查看状态，有三个节点，都是online状态。

2026-07-16 15:26:09 264

原创 mysql router学习-1 （简单的配置方式）

结论，这种配置方式，在conf配置文件中写死了primary和secondary，当实际的primary和secondary有变化的时候，不够灵活，可能和实际想象的效果不一样，不建议生产用，测试可以。--登录到8002端口， mysql route配置中，8002是primary，primary应对的hostname是mgr02 、mgr03。--连接到8002，是节点2和节点3 ，即mgr02，mgr03. 看起来是根据配置文件中的配置进行轮询的。-- 把节点1提升为primary ，任意节点执行。

2026-07-16 15:18:00 375

原创 pt-heartbeat学习

- pt的安装，下错包了，下载成了deb的包了（电脑客户端是Linux Mint,服务器是Redhat，应该下载rpm包）直接在Linux Mint上安装了。参考文档：https://docs.percona.com/percona-toolkit/pt-heartbeat.html。--从库上执行，要使用source-server-id，否则报错。--做成关闭脚本 stop_pt_heartbeat.sh。-- 主库上执行，执行完毕后，可以看到建立的表。--关闭后，/tmp下有这个文件。

2026-07-09 15:51:05 75

原创 mysql clone学习

- 做从库，略，从官网看，直接SOURCE_AUTO_POSITION = 1, 不像xtrabackup的官网，要做一个gtid_purge=XXX,然后再SOURCE_AUTO_POSITION = 1。，clone_dir不能存在。-- 这个时候，查看clone的库，文件夹里面没有information_schema 、 mysql 、 performance_schem等库。-- 将clone的mysql，clone到/mysql/mysql_clone。--如果有错误，则可以查看错误的信息。

2026-06-19 15:52:03 305

原创 xtrabackup 学习

命令： xtrabackup --user=bkpuser --host=127.0.0.1 --port=7000 --password=oracle --backup --stream=xbstream ./ > backup.xbstream ，可以执行，在当前目录生成backup.xbstream。参考文档：https://docs.percona.com/percona-xtrabackup/8.0/take-streaming-backup.html#use-streaming。

2026-06-19 15:32:01 269

原创安装Timezone时区文件

- update前检查，这里提示可以更新到45 Newest RDBMS DST version detected is DSTv45 .（因为我的Oracle HOme中之前已经有DST V45这个文件了，只是没有执行sql层面的更新）-- 从打补丁的log中，提示这个补丁已经作为子补丁已经存在了（我的库是19.31），也从侧面印证了，那些RU中，包含了时区文件，但是没有更新，需要执行sql更新后，新版本的时区文件生效。--在另一个19.31的RU的库中，查看39070269，确实有。

2026-06-04 10:56:05 313

原创单独导出Oracle中的job

参考文档：How to Capture DDL for Scheduler Jobs KB151090。方式2: 只适用于dbms_schedule,不适用dbms_job ,参考KB151090。expdp 导出job。

2026-05-08 15:47:34 230

原创 RU 19.31安装

2.1.1.1 OPatch Utility Information (19.31 read me中多了个CheckMinimumOPatchVersion)参考文档：Patch 39036936 - GI Release Update 19.31.0.0.260421。2.1.1.5 Run OPatch System Space Check (略)-- 一次性打GI和DB home的补丁。--节点1 Opatch冲突检查log。-- 分开打GI和DB的补丁。

2026-05-08 11:31:45 484

原创清理RU补丁.patch_storage文件夹

- 空间大小（du -sm 的命令的部分结果，占用空间大约12G，）-- 附加，删除rac下ru。-- 列出不活动的ru。--删除不活动的ru。

2026-05-08 11:24:08 144

原创 SYS_NC00002$之类的列

尽管知道这种列是怎么回事（最后发现还是忽略了default列）。当查询相关视图的时候，函数索引不存在，主键不存在，虚拟列不存在。一直不太了解这个列是怎么产生的，函数索引？曾经怀疑过是基于函数的索引，drop索引后遗留的问题，实际测试后，发现不是这个问题。但是还是有一个列的问题，导致思考了很久，查了很多文档，然后终于明白大约怎么回事。我的疑问，我的测试环境中的SYS_NC00002$列，是怎么产生的？看来还真是default列产生的虚拟列。ORA-14148 ，这个列是保护的列。

2026-04-28 16:51:23 249

原创 OS的load average很高

里面的load average 和今天发现的是一样的（至少前面的42亿多，是一样的）。不过这个文档中提到没有D进程，而且这个文档说的是exadata storage,也就是cell节点。在很多年前，看到过一个rac,节点1上的load average 在250左右，但是节点1的cpu使用率很低，也没有IO相关的负载。其中一个节点上load average已经快42亿了，另一个节点还不到5。在load average 42亿的节点上，看到%CPU使用率很低。通过以下命令，查看了下，确实有个进程状态的D.

2026-02-12 19:22:44 401

原创 ORA-20013: DBMS_QOPATCH ran mostly in non install area

-按照文档Datapatch fails with "ORA-20009:" “ORA-20013: DBMS_QOPATCH ran mostly in non install area” ORACLE_HOME is a SYMBOLIC LINK KB124873。以前打补丁的操作，在test库上安装ru,但后运行datapatch,然后其余三套库上直接运行datapatch.先打test库的ru,然后运行了datapatch，没有任何报错。--再次运行datapatch 报错。

2026-02-04 10:55:19 528

原创 RU 19.30 安装

参考文档：Patch 38629535 - GI Release Update 19.30.0.0.260120。分别在GI和Oracle Home下执行。-- 一次性打GI和DB home的补丁。-- 修复问题后， resume。-- 分开打GI和DB的补丁。

2026-02-04 09:22:50 576

原创 ORA-20001: Latest xml inventory is not loaded into table

- 在logfile /u01/app/oracle/product/19.0.0/db_1/rdbms/log/qopatch_log.log中，出现以下错误。--当时客户端环境是中文，locale信息如下：查看LANG是zh_CN.UTF-8。-- 查看服务器上的locale信息，LANG是en_US.UTF-8。-- 回退补丁，重新打补丁，然后再次datapatch，问题解决。--换成英文继续datapatch,还是同样的问题。-- 查询OPATCH_XML_INV，出现错误。

2026-01-23 13:41:53 304

原创 Oracle只恢复部分表空间

现在的测试方式，restore所需的表空间，在recover之前，不需要重建控制文件，在recover的时候，使用recover database skip forever tablespace XXX ,排除掉不需要recover的database，然后开库。和之前的测试，不同的地方，之前的测试，restore所需的表空间，在recover之前，使用重建控制文件的方式，将控制文件中不需要的表空间文件排除掉。-- recover ,skip掉无关的表空间。4 禁用触发器，加TEMP表空间。

2025-12-05 13:23:25 765

原创 alter begin/end backup

- 结论，begin/end backup .这种方式，在RMAN中看不到备份记录。-- 从alert 中看，有记录begin backup / end backup。-- 进行begin backup，备份完成后，end backup。--从rman中看，并没有这些备份。

2025-11-27 14:32:26 250

原创 PSU过程11.2.0.4.250415

opatch版本： 11.2.0.3.49 or later。-- opatch auto 打补丁。

2025-11-10 15:02:44 518 2

原创 MySQL Binlog File_size为0的测试

-20251105 add 测试设置binlog_expire_logs_seconds，是否会自动清理有问题的binlog。-- 测试flush log，是否会删除file_size为0的log （没有删除掉，是因为和expire参数有关）-- 查看binlog_expire_logs_seconds，设置为1天，然后flush log。-- 发现flush log的时候，有个告警，再次查看binlog，binlog已经被清理掉了。--binlog size为0的模拟。-- 查看binlog。

2025-11-05 14:09:36 361

原创 RU 19.29 relink失败

1 查看官方文档，对rpm包的要求，发现一些包居然没有的，可能在升级到oracle linux 8.10后，没有按照Linux 8的安装方式再次安装所需的rpm包，重新安装缺失包。1 尝试sqlplus启动库，发下无法调用sqlplus命令，看错误，无法链接某些*.so之类的文件。3 which sqlplus，能返回结果，但是无法sqlplus登录。升级后，relink无问题，数据库可以正常登录打开。2 安装包完毕后，重新relink，问题解决。2 which gcc，发现没有gcc命令。

2025-10-24 09:24:51 593

原创 Oracle 19.29

参考文档：Oracle® Database Patch 38298204 - GI Release Update 19.29.0.0.251021。分别在GI和Oracle Home下执行。-- 一次性打GI和DB home的补丁。-- log 节点1 grid。-- 分开打GI和DB的补丁。-- 节点1 oracle。-- 节点2 oracle。-- 节点2 grid。

2025-10-23 13:36:47 867

转载 [转载]升级后，删除多余的kernel

软件包会自动添加到排除列表中，以防止删除或更新重要的文件。原位升级后，您必须在从系统中删除它们之前，从排除列表中删除这些。禁用在 RHEL 8 上无法安装或使用其软件包的 YUM 存储库。如果您的系统的内核软件包有不同的名称，比如在实时系统上，请使用正确的软件包名称替换。从 RHEL 8 系统中删除剩余的 RHEL 7 软件包，包括旧的内核软件包和。从引导装载程序条目中删除旧内核。从旧内核中删除弱模块。删除剩余的 RHEL 7 软件包，包括剩余的。如果您的系统在 IBM Z 构架上，请更新。

2025-09-24 08:31:42 255 1

原创 redhat7.4升级到Oracle Linux8.10

因为原来的OS是redhat，使用了Oracle Linux的源后，虽然update了，但是kernel还是redhat的，不是oracle uek的kernel。存在1个Inhibitors:，查看相关日志，发现提示有多个linux 7的YUM源，解决方法：安装UEK的kernel ， yum install kernel-uek。/etc/yum.repos.d下，把7的yum源文件，重命名。-- 将redhat的YUM源换成oracle的源。-- 升级完成后，kernel的变化。

2025-09-22 16:17:13 549

原创 Oracle Client安装补丁

- 使用SQL PLUS连接，发现client的版本是19.3。-- 使用OPatch查看版本，Client没有安装任何补丁。-- 查看CLient版本，版本是19.28。-- 给Client安装19.28。

2025-09-19 09:57:04 394

转载 Troubleshooting Database Contention With V$Wait_Chains (Doc ID 1428210.1)

参考文档：Troubleshooting Database Contention With V$Wait_Chains (Doc ID 1428210.1)无意间看到的，感觉很有意思，转载。

2025-09-10 15:06:12 164

原创 Linux Mint更换主机名后，edge无法启动

把Linux Mint更换了主机名，发现edge无法启动，转圈圈，然后消失。进入到配置文件夹，清理配置文件，再次启动正常。

2025-09-08 13:53:31 539

原创 Linux MInt启动速度的优化

随后，查看官方对这些服务的解释说明，将可以disable的服务，disable后，再次启动。把Windows改造成Linux 后，发现启动速度很慢。

2025-09-08 08:54:27 514

原创 Linux Mint下网卡的设置

把15年旧的台式机，从Windows改造成了Linux Mint。发现USB无线网卡不能识别。在github上下载对应的网卡的驱动，make@make install后，问题依旧。使用lsusb命令查看，发现网卡是：Driver CDROM Mode。随后，将该命令绑定到UDEV , 使其开机后生效。使用以下命令，手工可以使得网卡生效。随后，开机后，网卡正常生效。需要拔掉再插上，才能识别。

2025-09-08 08:42:43 552

原创使用leapp升级Linux

https://docs.oracle.com/zh-cn/learn/ol-linux-leapp/index.html#introduction 使用 Leapp 升级 Oracle Linux。-- relink ，因为上面跑的有Oracle，需要relink。-- 升级过程中，会mount一些目录，升级完毕后，这些目录消失。-- 升级前检查，出现Inhibitors 要处理。-- 预升级preupgrade。-- 升级后的版本和kernel。-- repo的设置，-- 安装leapp。

2025-08-29 18:36:49 846

原创 Log Miner的一些小记录

当日志挖完的时候，也就是挖的数据，全部存到v$logmnr_contents中的时候，这个时候，翻译完毕了所有的归档日志，会提示sequence -1 ,DummyForCrossThreadMine。所以感觉，是先读取归档日志，再存放在视图中（之前的理解：挖完日志后，是立刻就有内容，是存放在内存中的）当挖出来的东西，在V$logmnr_contents中的时候，是存在内存中的，还是存在在其他地方？比如，挖出来的数据非常多，如果存在内存中，那么内存中能否存下？最近在做Log Miner，有一些想法。

2025-08-19 14:48:02 537

原创 Oracle参数Process

测试6 ，在测试5的基础上，将process变大，变大到600,理论上推导出来的session 600*1.5+22 = 922, 没有超过现在的session 1500。以下测试，在process和session参数关系正常的情况下（符合上面1.5*process + 22），单独更改session或process，会有什么变化。测试8 在测试7的基础上，也就是process和session的值，符合推导公式的时候，将process该小。1 数据库参数，process和session的关系。

2025-08-07 11:27:59 718

原创 Patch level不一致，导致的集群无法启动

4 dump出olr的内容，发现olr中的patch level确实不一样，参考文档Grid Infrastructure 启动的五大问题 (Doc ID 1526147.1)，尝试重建olr，无效。安装完毕后，发现集群的CRS无法启动。查看节点1和节点2上的patch ，发现节点2上多了29517242这个补丁，这个是19.3。2 回退掉补丁后，尝试使用opatchauto方式打GI补丁，可以正常打上补丁，但问题依旧。5 发现节点2上多了29517242这个补丁，这个是19.3 ，卸载补丁，无法卸载。

2025-07-26 10:44:29 1285

原创 RU 19.28安装

参考文档： Supplemental Readme - Grid Infrastructure Release Update 12.2.0.1.x / 18c /19c (Doc ID 2246888.1)1 关闭掉GI和DB （测试之前，GI和DB一直都是关闭的，没有启动）7 datapatch （在其中一个节点执行）6 启动crs （打完后，自动启动）#### 安装各个补丁的log。使用手工方式打RU19.28。-- oracle 补丁。3 给GI打PATCH。

2025-07-26 10:23:11 814

MHA0.58安装包及安装文档

空空如也