标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (661)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
分类目录归档:数据库
arm环境vg损坏mysql数据库恢复
国庆节期间接到朋友咨询,原先在vg中的磁盘被重新pvcreate了,想恢复原磁盘中的mysql数据库

通过分析系统的history日志,发现操作不是简单的pvcreate,我简单梳理下操作步骤
故障之前磁盘情况
[root@0002 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 200G 0 disk ├─vda1 253:1 0 600M 0 part /boot/efi ├─vda2 253:2 0 1G 0 part /boot └─vda3 253:3 0 38.4G 0 part ├─klas-root 252:0 0 34.4G 0 lvm / └─klas-swap 252:1 0 4G 0 lvm [SWAP] vdb 253:16 0 1000G 0 disk └─vdb1 253:17 0 500G 0 part └─mysql-mysql--mycg 252:2 0 500G 0 lvm /mysql
这里可以看到出来vdb磁盘一共1000G,分区vdb1 为500G,然后这500G加入到vg中并分配了lv.
vdb磁盘现状
[root@0002 mysql]# lsblk /dev/vdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vdb 253:16 0 1000G 0 disk └─vdb1 253:17 0 1000G 0 part Disk /dev/vdb: 1000 GiB, 1073741824000 bytes, 2097152000 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5a6aaeee Device Boot Start End Sectors Size Id Type /dev/vdb1 2048 2097151999 2097149952 1000G 8e Linux LVM
这里基本上可以确定,vdb1磁盘分区从以前的500G变成了1000G(也就是说被重新分区了,后续和现场沟通确认进行了重新分区操作)
通过history日志追述大概的操作过程
898 [2025-09-28 11:55:13][root]fdisk -l 899 [2025-09-28 11:55:21][root]df -h 900 [2025-09-28 11:56:41][root]lsblk 901 [2025-09-28 11:59:44][root]fdisk /dev/vdb 902 [2025-09-28 12:00:46][root]partprobe /dev/vdb 903 [2025-09-28 12:00:50][root]pvresize /dev/vdb1 904 [2025-09-28 12:00:56][root]df -h 905 [2025-09-28 12:01:25][root]vgdisplay mysql 906 [2025-09-28 12:01:40][root]lsblk 907 [2025-09-28 12:02:05][root]sudo partprobe /dev/vdb 908 [2025-09-28 12:02:10][root]pvresize /dev/vdb1 909 [2025-09-28 12:02:27][root]sudo pvresize /dev/vdb1 910 [2025-09-28 12:03:07][root]sudo pvcreate /dev/vdb1 911 [2025-09-28 12:03:22][root]sudo pvscan 912 [2025-09-28 12:03:30][root]sudo pvdisplay 913 [2025-09-28 12:05:37][root]parted /dev/vdb 914 [2025-09-28 12:06:11][root]pvresize /dev/vdb1 915 [2025-09-28 12:06:15][root]lsblk 916 [2025-09-28 12:09:48][root]lvextend -l +100%FREE /dev/mysql/mysql--mycg 917 [2025-09-28 12:10:00][root]cd /dev/mysql/ 918 [2025-09-28 12:10:01][root]ll 919 [2025-09-28 12:10:20][root]pwd 920 [2025-09-28 12:10:32][root]lvextend -l +100%FREE /dev/mysql/mysql-mycg 921 [2025-09-28 12:10:55][root]lsblk /dev/vdb
基本上可以确定9月28日先进行了fdisk分区操作,然后尝试pvresize 操作[应该不会成功,因为重新分区导致pv信息丢失],然后进行了pvcreate之后再次进行parted分区操作,再pvresize,lvextend操作[同理pv信息丢失应该不会成功],然后10月5日继续进行的部分操作
956 [2025-10-05 08:29:27][root]umount /mysql 957 [2025-10-05 08:29:38][root]lsof /mysql 958 [2025-10-05 08:29:58][root]service mysqld stop 959 [2025-10-05 08:30:02][root]umount /mysql 960 [2025-10-05 08:30:05][root]lsof /mysql 961 [2025-10-05 08:30:23][root]cd / 962 [2025-10-05 08:30:25][root]umount /mysql 963 [2025-10-05 08:30:34][root]pvcreate --force /dev/vdb1 964 [2025-10-05 08:30:47][root]vgextend mysql /dev/vdb1 965 [2025-10-05 08:31:02][root]df -h 966 [2025-10-05 08:31:33][root]pvdisplay /dev/vdb1 967 [2025-10-05 08:31:41][root]pvcreate --force /dev/vdb1 968 [2025-10-05 08:32:11][root]lvs | grep mysql-mysql--mycg 969 [2025-10-05 08:32:19][root]dmsetup ls | grep mysql 970 [2025-10-05 08:32:38][root]fuser /dev/vdb1 971 [2025-10-05 08:32:41][root]lsof /dev/vdb1 972 [2025-10-05 08:32:50][root]pvcreate --force /dev/vdb1 973 [2025-10-05 08:33:14][root]reboot 974 [2025-10-05 08:36:23][root]pvcreate --force /dev/vdb1 975 [2025-10-05 08:36:47][root]lvdisplay /dev/mapper/mysql-mysql--mycg 976 [2025-10-05 08:36:53][root]vgextend mysql /dev/vdb1 977 [2025-10-05 08:37:10][root]lvextend -l +100%FREE /dev/mysql/mysql--mycg
初步看,应该是先尝试umount /dev/vdb1,但是没有成功,然后直接reboot重启了主机,起来之后,进行了pvcreate[操作成功],vgextend,lvextend等操作[失败,因为vg里面的之前的pv信息已经丢失],而且之前lv无法mount成功,数据库文件/备份均在这个lv里面,而且从库很久之前没有正常同步.基于这样的情况,就一定要对vdb磁盘中数据进行恢复.查看操作系统信息,确认是arm系统

由于arm系统一般工具均无法正常解析,只能让客户把磁盘挂载到x86环境进行处理,通过专业恢复工具解析,运气不错可以直接读取数据

传输数据到客户服务器中,并成功启动mysql,客户测试业务没有任何问题,数据完整恢复

11.2.0.4升级到19c详细操作过程
随着硬件生命周期,数据库等保要求等,不少客户需要把数据库从11.2.0.4版本升级到19c.对于这样的客户的核心生产库升级,一般考虑到回退情况,大部分会选择异机进行升级,提供一个完整版测试
在源库(11.2.0.4)中做升级之前检查
--触发器检查(禁用和启用脚本生成)
SELECT 'ALTER TRIGGER ' || owner || '.' || trigger_name || ' DISABLE;' AS disable_commands
FROM dba_triggers
WHERE trigger_type IN ('BEFORE EVENT', 'AFTER EVENT')
AND triggering_event LIKE '%DDL%'
AND status = 'ENABLED';
SELECT 'ALTER TRIGGER ' || owner || '.' || trigger_name || ' ENABLE;' AS disable_commands
FROM dba_triggers
WHERE trigger_type IN ('BEFORE EVENT', 'AFTER EVENT')
AND triggering_event LIKE '%DDL%'
AND status = 'ENABLED';
--收集字典统计信息
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
--检查时区信息
select * from v$timezone_file;
select distinct owner from dba_tab_columns where
DATA_TYPE='TIMESTAMP(6) WITH TIME ZONE';
--物化视图刷新检查
SELECT DISTINCT(TRUNC(last_refresh)) FROM dba_snapshot_refresh_times;
SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;
--无效index检查
set linesize 400
select owner,index_name from dba_indexes where status in ('INVALID','UNUSABLE') ;
select index_owner,index_name,partition_name,status from dba_ind_partitions where status in ('INVALID','UNUSABLE') ;
--清空审计表和所属表空间检查
truncate table aud$;
SELECT owner,tablespace_name FROM dba_tables WHERE table_name='AUD$';
--清理19c中无法升级组件
alter session set nls_language='American';
SET ECHO ON;
SET SERVEROUTPUT ON;
@olspreupgrade.sql
@emremove.sql
@catnoamd.sql
@catnoexf.sql
@$ORACLE_HOME/apex/apxremov.sql
@?/rdbms/admin/utlprp.sql 32
select owner,object_type from dba_objects where object_name =upper('htmldb_system');
drop package htmldb_system;
drop public synonym htmldb_system;
--检查数据文件不处于备份状态
SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
--清空回收站
PURGE DBA_RECYCLEBIN;
--检查 SYS 及 SYSTEM默认表空间
SELECT username, default_tablespace FROM dba_users WHERE username in ('SYS','SYSTEM');
--检查组件状态
set pagesize 500
set linesize 400
col comp_name for a40
select substr(comp_name,1,40) comp_name, status, substr (version,1,10) version from dba_registry order by comp_name;
--记录无效对象
create table system.invalid_obj_10g_beforeup tablespace sysaux as select substr(object_name,1,40) object_name,
substr(owner,1,15) owner, object_type from dba_objects where status='INVALID' order by owner,object_type;
--禁用Block Change Tracking
SELECT filename, status, bytes FROM v$block_change_tracking;
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
--执行 preupgrade 脚本
$ORACLE_HOME/jdk/bin/java -jar /u01/xff/preupgrade.jar FILE TEXT DIR /tmp
@/tmp/preupgrade_fixups.sql
--执行dbupgdiag.sql脚本
alter session set nls_language='American';
SET ECHO ON;
SET SERVEROUTPUT ON;
@dbupgdiag.sql
rman备份还原数据库
--在11.2.0.4库备份操作 backup filesperset = 5 as compressed backupset database format '/u01/rmanback/full_%T_%U.rman'; sql 'alter system archive log current'; sql 'alter system archive log current'; Backup filesperset = 10 as compressed backupset archivelog all format '/u01/rmanback/arch_%T_%U.rman' not backed up delete input; backup format '/u01/rmanback/ctl_%T_%U.rman' current controlfile; --在19c库还原操作 SQL>startup nomount pfile='/tmp/pfile' RMAN> restore controlfile from '/u01/rmanback/ctl_20251003_0a459rsp_1_1.rman'; RMAN> alter database mount; RMAN> catalog start with '/u01/orabak/'; RMAN> restore database; RMAN> recover database; --可以增量追加归档 SQL> alter database open resetlogs upgrade;
正式升级操作(19c环境)
startup pfile='/u01/xff/pfile.upgrade' mount; alter database open upgrade; export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 cd $ORACLE_HOME/bin ./dbupgrade sqlplus / as sysdba startup @?/rdbms/admin/utlusts.sql TEXT @?/rdbms/admin/utlrp.sql 32 @?/rdbms/admin/utlusts.sql TEXT set pagesize500 set linesize 400 col comp_name for a40 select substr(comp_name,1,40) comp_name, status, substr (version,1,10) version from dba_registry order by comp_name;
升级完成后操作
--执行postupgrade_fixups @/tmp/postupgrade_fixups.sql --收集字典统计信息 EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS; EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; --升级时区 cd $ORACLE_HOME/rdbms/admin @utltz_countstats.sql @utltz_countstar.sql @?/rdbms/admin/utltz_upg_check.sql @?/rdbms/admin/utltz_upg_apply.sql
主要日志
--升级操作日志
[oracle@oracledb:/u01/app/oracle/product/19c/db/bin]$ ./dbupgrade
Argument list for [/u01/app/oracle/product/19c/db/rdbms/admin/catctl.pl]
For Oracle internal use only A = 0
Run in c = 0
Do not run in C = 0
Input Directory d = 0
Echo OFF e = 1
Simulate E = 0
Forced cleanup F = 0
Log Id i = 0
Child Process I = 0
Log Dir l = 0
Priority List Name L = 0
Upgrade Mode active M = 0
SQL Process Count n = 0
SQL PDB Process Count N = 0
Open Mode Normal o = 0
Start Phase p = 0
End Phase P = 0
Reverse Order r = 0
AutoUpgrade Resume R = 0
Script s = 0
Serial Run S = 0
RO User Tablespaces T = 0
Display Phases y = 0
Debug catcon.pm z = 0
Debug catctl.pl Z = 0
catctl.pl VERSION: [19.0.0.0.0]
STATUS: [Production]
BUILD: [RDBMS_19.16.0.0.0DBRU_LINUX.X64_220701]
/u01/app/oracle/product/19c/db/rdbms/admin/orahome = [/u01/app/oracle/product/19c/db]
/u01/app/oracle/product/19c/db/bin/orabasehome = [/u01/app/oracle/product/19c/db]
catctlGetOraBaseLogDir = [/u01/app/oracle/product/19c/db]
Analyzing file /u01/app/oracle/product/19c/db/rdbms/admin/catupgrd.sql
Log file directory = [/tmp/cfgtoollogs/upgrade20251003103800]
catcon::set_log_file_base_path: ALL catcon-related output will be written to
[/tmp/cfgtoollogs/upgrade20251003103800/catupgrd_catcon_15770.lst]
catcon::set_log_file_base_path: catcon: See [/tmp/cfgtoollogs/upgrade20251003103800/catupgrd*.log]
files for output generated by scripts
catcon::set_log_file_base_path: catcon: See [/tmp/cfgtoollogs/upgrade20251003103800/catupgrd_*.lst]
files for spool files, if any
Number of Cpus = 4
Database Name = orcl
DataBase Version = 11.2.0.4.0
catcon::set_log_file_base_path: ALL catcon-related output will be written to
[/u01/xxx/upgrade20251003103801/catupgrd_catcon_15770.lst]
catcon::set_log_file_base_path: catcon: See [/u01/xxx/upgrade20251003103801/catupgrd*.log]
files for output generated by scripts
catcon::set_log_file_base_path: catcon: See [/u01/xxx/upgrade20251003103801/catupgrd_*.lst]
files for spool files, if any
Log file directory = [/u01/xxx/upgrade20251003103801]
Parallel SQL Process Count = 4
Components in [orcl]
Installed [APS CATALOG CATJAVA CATPROC CONTEXT JAVAVM ORDIM OWM SDO XDB XML XOQ]
Not Installed [APEX DV EM MGW ODM OLS RAC WK]
DataBase Version = 11.2.0.4.0
------------------------------------------------------
Phases [0-107] Start Time:[2025_10_03 10:38:01]
------------------------------------------------------
*********** Executing Change Scripts ***********
Serial Phase #:0 [orcl] Files:1 Time: 30s
*************** Catalog Core SQL ***************
Serial Phase #:1 [orcl] Files:5 Time: 18s
Restart Phase #:2 [orcl] Files:1 Time: 0s
*********** Catalog Tables and Views ***********
Parallel Phase #:3 [orcl] Files:19 Time: 9s
Restart Phase #:4 [orcl] Files:1 Time: 0s
************* Catalog Final Scripts ************
Serial Phase #:5 [orcl] Files:7 Time: 7s
***************** Catproc Start ****************
Serial Phase #:6 [orcl] Files:1 Time: 5s
***************** Catproc Types ****************
Serial Phase #:7 [orcl] Files:2 Time: 4s
Restart Phase #:8 [orcl] Files:1 Time: 0s
**************** Catproc Tables ****************
Parallel Phase #:9 [orcl] Files:70 Time: 9s
Restart Phase #:10 [orcl] Files:1 Time: 0s
************* Catproc Package Specs ************
Serial Phase #:11 [orcl] Files:1 Time: 25s
Restart Phase #:12 [orcl] Files:1 Time: 0s
************** Catproc Procedures **************
Parallel Phase #:13 [orcl] Files:95 Time: 2s
Restart Phase #:14 [orcl] Files:1 Time: 0s
Parallel Phase #:15 [orcl] Files:122 Time: 4s
Restart Phase #:16 [orcl] Files:1 Time: 0s
Serial Phase #:17 [orcl] Files:25 Time: 1s
Restart Phase #:18 [orcl] Files:1 Time: 0s
***************** Catproc Views ****************
Parallel Phase #:19 [orcl] Files:32 Time: 6s
Restart Phase #:20 [orcl] Files:1 Time: 0s
Serial Phase #:21 [orcl] Files:3 Time: 4s
Restart Phase #:22 [orcl] Files:1 Time: 1s
Parallel Phase #:23 [orcl] Files:25 Time: 79s
Restart Phase #:24 [orcl] Files:1 Time: 0s
Parallel Phase #:25 [orcl] Files:12 Time: 49s
Restart Phase #:26 [orcl] Files:1 Time: 0s
Serial Phase #:27 [orcl] Files:1 Time: 0s
Serial Phase #:28 [orcl] Files:4 Time: 1s
Serial Phase #:29 [orcl] Files:1 Time: 0s
Restart Phase #:30 [orcl] Files:1 Time: 0s
*************** Catproc CDB Views **************
Serial Phase #:31 [orcl] Files:1 Time: 0s
Restart Phase #:32 [orcl] Files:1 Time: 0s
Serial Phase #:34 [orcl] Files:1 Time: 0s
***************** Catproc PLBs *****************
Serial Phase #:35 [orcl] Files:297 Time: 9s
Serial Phase #:36 [orcl] Files:1 Time: 0s
Restart Phase #:37 [orcl] Files:1 Time: 0s
Serial Phase #:38 [orcl] Files:10 Time: 2s
Restart Phase #:39 [orcl] Files:1 Time: 0s
*************** Catproc DataPump ***************
Serial Phase #:40 [orcl] Files:3 Time: 21s
Restart Phase #:41 [orcl] Files:1 Time: 0s
****************** Catproc SQL *****************
Parallel Phase #:42 [orcl] Files:13 Time: 50s
Restart Phase #:43 [orcl] Files:1 Time: 1s
Parallel Phase #:44 [orcl] Files:11 Time: 3s
Restart Phase #:45 [orcl] Files:1 Time: 0s
Parallel Phase #:46 [orcl] Files:3 Time: 0s
Restart Phase #:47 [orcl] Files:1 Time: 0s
************* Final Catproc scripts ************
Serial Phase #:48 [orcl] Files:1 Time: 5s
Restart Phase #:49 [orcl] Files:1 Time: 0s
************** Final RDBMS scripts *************
Serial Phase #:50 [orcl] Files:1 Time: 8s
************ Upgrade Component Start ***********
Serial Phase #:51 [orcl] Files:1 Time: 0s
Restart Phase #:52 [orcl] Files:1 Time: 0s
********** Upgrading Java and non-Java *********
Serial Phase #:53 [orcl] Files:2 Time: 161s
***************** Upgrading XDB ****************
Restart Phase #:54 [orcl] Files:1 Time: 0s
Serial Phase #:56 [orcl] Files:3 Time: 9s
Serial Phase #:57 [orcl] Files:3 Time: 1s
Parallel Phase #:58 [orcl] Files:10 Time: 1s
Parallel Phase #:59 [orcl] Files:25 Time: 2s
Serial Phase #:60 [orcl] Files:4 Time: 3s
Serial Phase #:61 [orcl] Files:1 Time: 0s
Serial Phase #:62 [orcl] Files:32 Time: 1s
Serial Phase #:63 [orcl] Files:1 Time: 0s
Parallel Phase #:64 [orcl] Files:6 Time: 4s
Serial Phase #:65 [orcl] Files:2 Time: 8s
Serial Phase #:66 [orcl] Files:3 Time: 29s
**************** Upgrading ORDIM ***************
Restart Phase #:67 [orcl] Files:1 Time: 0s
Serial Phase #:69 [orcl] Files:1 Time: 0s
Parallel Phase #:70 [orcl] Files:2 Time: 14s
Restart Phase #:71 [orcl] Files:1 Time: 0s
Parallel Phase #:72 [orcl] Files:2 Time: 0s
Serial Phase #:73 [orcl] Files:2 Time: 0s
***************** Upgrading SDO ****************
Restart Phase #:74 [orcl] Files:1 Time: 0s
Serial Phase #:76 [orcl] Files:1 Time: 16s
Serial Phase #:77 [orcl] Files:2 Time: 0s
Restart Phase #:78 [orcl] Files:1 Time: 0s
Serial Phase #:79 [orcl] Files:1 Time: 8s
Restart Phase #:80 [orcl] Files:1 Time: 0s
Parallel Phase #:81 [orcl] Files:3 Time: 10s
Restart Phase #:82 [orcl] Files:1 Time: 0s
Serial Phase #:83 [orcl] Files:1 Time: 2s
Restart Phase #:84 [orcl] Files:1 Time: 0s
Serial Phase #:85 [orcl] Files:1 Time: 4s
Restart Phase #:86 [orcl] Files:1 Time: 0s
Parallel Phase #:87 [orcl] Files:4 Time: 28s
Restart Phase #:88 [orcl] Files:1 Time: 0s
Serial Phase #:89 [orcl] Files:1 Time: 0s
Restart Phase #:90 [orcl] Files:1 Time: 0s
Serial Phase #:91 [orcl] Files:2 Time: 4s
Restart Phase #:92 [orcl] Files:1 Time: 0s
Serial Phase #:93 [orcl] Files:1 Time: 0s
Restart Phase #:94 [orcl] Files:1 Time: 1s
******* Upgrading ODM, WK, EXF, RUL, XOQ *******
Serial Phase #:95 [orcl] Files:1 Time: 6s
Restart Phase #:96 [orcl] Files:1 Time: 0s
*********** Final Component scripts ***********
Serial Phase #:97 [orcl] Files:1 Time: 1s
************* Final Upgrade scripts ************
Serial Phase #:98 [orcl] Files:1 Time: 22s
******************* Migration ******************
Serial Phase #:99 [orcl] Files:1 Time: 15s
*** End PDB Application Upgrade Pre-Shutdown ***
Serial Phase #:100 [orcl] Files:1 Time: 0s
Serial Phase #:101 [orcl] Files:1 Time: 0s
Serial Phase #:102 [orcl] Files:1 Time: 35s
***************** Post Upgrade *****************
Serial Phase #:103 [orcl] Files:1 Time: 14s
**************** Summary report ****************
Serial Phase #:104 [orcl] Files:1 Time: 0s
*** End PDB Application Upgrade Post-Shutdown **
Serial Phase #:105 [orcl] Files:1 Time: 0s
Serial Phase #:106 [orcl] Files:1 Time: 0s
Serial Phase #:107 [orcl] Files:1 Time: 50s
------------------------------------------------------
Phases [0-107] End Time:[2025_10_03 10:51:23]
------------------------------------------------------
Grand Total Time: 802s
LOG FILES: (/u01/xxx/upgrade20251003103801/catupgrd*.log)
Upgrade Summary Report Located in:
/u01/xxx/upgrade20251003103801/upg_summary.log
Grand Total Upgrade Time: [0d:0h:13m:22s]
--组件状态
SQL>@?/rdbms/admin/utlusts.sql TEXT
Oracle Database Release 19 Post-Upgrade Status Tool 10-03-2025 10:53:4
Database Name: ORCL
Component Current Full Elapsed Time
Name Status Version HH:MM:SS
Oracle Server UPGRADED 19.16.0.0.0 00:05:52
JServer JAVA Virtual Machine UPGRADED 19.16.0.0.0 00:01:28
Oracle XDK UPGRADED 19.16.0.0.0 00:00:16
Oracle Database Java Packages UPGRADED 19.16.0.0.0 00:00:05
OLAP Analytic Workspace UPGRADED 19.16.0.0.0 00:00:04
Oracle Text UPGRADED 19.16.0.0.0 00:00:18
Oracle Workspace Manager UPGRADED 19.16.0.0.0 00:00:26
Oracle Real Application Clusters OPTION OFF 19.16.0.0.0 00:00:00
Oracle XML Database UPGRADED 19.16.0.0.0 00:00:58
Oracle Multimedia UPGRADED 19.16.0.0.0 00:00:13
Spatial UPGRADED 19.16.0.0.0 00:01:11
Oracle OLAP API UPGRADED 19.16.0.0.0 00:00:05
Datapatch 00:00:19
Final Actions 00:00:37
Post Upgrade 00:00:12
Total Upgrade Time: 00:11:54
Database time zone version is 14. It is older than current release time
zone version 32. Time zone upgrade is needed using the DBMS_DST package.
--编译无效对象
SQL>@?/rdbms/admin/utlrp.sql 32
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2025-10-03 10:53:48
DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END 2025-10-03 10:55:35
DOC> The following query reports the number of invalid objects.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#
OBJECTS WITH ERRORS
-------------------
0
DOC> The following query reports the number of exceptions caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC> Note: Typical compilation errors (due to coding errors) are not
DOC> logged into this table: they go into DBA_ERRORS instead.
DOC>#
ERRORS DURING RECOMPILATION
---------------------------
0
--编译之后组件状态正常
SQL>@?/rdbms/admin/utlusts.sql TEXT
Oracle Database Release 19 Post-Upgrade Status Tool 10-03-2025 10:55:3
Database Name: ORCL
Component Current Full Elapsed Time
Name Status Version HH:MM:SS
Oracle Server VALID 19.16.0.0.0 00:05:52
JServer JAVA Virtual Machine VALID 19.16.0.0.0 00:01:28
Oracle XDK VALID 19.16.0.0.0 00:00:16
Oracle Database Java Packages VALID 19.16.0.0.0 00:00:05
OLAP Analytic Workspace VALID 19.16.0.0.0 00:00:04
Oracle Text VALID 19.16.0.0.0 00:00:18
Oracle Workspace Manager VALID 19.16.0.0.0 00:00:26
Oracle Real Application Clusters OPTION OFF 19.16.0.0.0 00:00:00
Oracle XML Database VALID 19.16.0.0.0 00:00:58
Oracle Multimedia VALID 19.16.0.0.0 00:00:13
Spatial VALID 19.16.0.0.0 00:01:11
Oracle OLAP API VALID 19.16.0.0.0 00:00:05
Datapatch 00:00:19
Final Actions 00:00:37
Post Upgrade 00:00:12
Post Compile 00:01:47
Total Upgrade Time: 00:13:41
Database time zone version is 14. It is older than current release time
zone version 32. Time zone upgrade is needed using the DBMS_DST package.
--时区升级之后结果
SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
2 FROM DATABASE_PROPERTIES
3 WHERE PROPERTY_NAME LIKE 'DST_%'
4 ORDER BY PROPERTY_NAME;
PROPERTY_NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
DST_PRIMARY_TT_VERSION
32
DST_SECONDARY_TT_VERSION
0
DST_UPGRADE_STATE
NONE
3 rows selected.
具体参考:Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单 (Doc ID 2577572.1)
Postgres数据库truncate表无有效备份恢复
创建一个Postgres表,并插入数据
postgres=# CREATE TABLE "PeisInterfaceLog"( postgres(# "PeisInterfaceLogId" text, postgres(# "PeisDepartmentId" text, postgres(# "PeisDepartmentName" text, postgres(# "PeisInterfaceSubjectType" text, postgres(# "PeisInterfaceSubjectId" text, postgres(# "PeisInterfaceNo" text, postgres(# "PeisInterfaceName" text, postgres(# "PeisInterfaceDirection" text, postgres(# "PeisInterfaceCallAddress" text, postgres(# "PeisInterfaceLogStartTime" timestamp, postgres(# "PeisInterfaceInputContent" json, postgres(# "PeisInterfaceInputTranscodeContent" json, postgres(# "PeisInterfaceOutContent" json, postgres(# "PeisInterfaceOutTranscodeContent" json, postgres(# "PeisInterfaceSuccessSign" int4, postgres(# "PeisInterfaceLogStatusCode" text, postgres(# "PeisInterfaceLogNote" text, postgres(# "PeisInterfaceLogTimestamp" timestamp, postgres(# "PeisInterfaceLogInfo" text, postgres(# "PeisPatientRegisterId" text postgres(# ); CREATE TABLE postgres=# \i /postgres/COPY/public_copy.sql SET COPY 722957 postgres=# select count(1) from "PeisInterfaceLog"; count -------- 722957 (1 row)
验证truncate操作,引起Postgres中oid的变化
postgres=# checkpoint;
CHECKPOINT
postgres=# show data_directory;
data_directory
----------------
/pgdata
(1 row)
postgres=# select oid, datname from pg_database ;
oid | datname
-------+-----------
13676 | postgres
1 | template1
13675 | template0
(3 rows)
postgres=# select relname, relowner, relfilenode from pg_class where relowner = 10 and relname like '%PeisInterfaceLog%';
relname | relowner | relfilenode
------------------+----------+-------------
PeisInterfaceLog | 10 | 16384
(1 row)
postgres=# truncate table "PeisInterfaceLog";
TRUNCATE TABLE
postgres=# select count(1) from "PeisInterfaceLog";
count
-------
0
(1 row)
postgres=# select relname, relowner, relfilenode from pg_class where relowner = 10 and relname like '%PeisInterfaceLog%';
relname | relowner | relfilenode
------------------+----------+-------------
PeisInterfaceLog | 10 | 16394
(1 row)
使用工具进行初始化字典信息
PDU.public=# b;
开始初始化...
-pg_database:</pgdata/global/1262>
数据库:postgres
-pg_schema:</pgdata/base/13676/2615>
-pg_class:</pgdata/base/13676/1259> 共88行
-pg_attribute:</pgdata/base/13676/1249> 共2950行
模式:
▌ public 1张表
PDU.public=# use postgres;
┌────────────────────────────────────────┐
│ 模式 │ 表数量 │
├────────────────────────────────────────┤
│ public │ 1 │
└────────────────────────────────────────┘
postgres.public=# set public;
┌──────────────────────────────────────────────────┐
│ 表名 │ 表大小 │
├──────────────────────────────────────────────────┤
│ PeisInterfaceLog │ 0 │
└──────────────────────────────────────────────────┘
仅显示表大小排名前 1 的表名
postgres.public=# \d PeisInterfaceLog;
┌──────────────────────────────────────────────────────────────┐
│ 列类型 │
└──────────────────────────────────────────────────────────────┘
text,text,text,text,text,text,text,text,text,timestamp,json,json,json,json,int4,text,text,timestamp,text,text
配置软件磁盘扫描操作(pdu.ini中配置)
#dropScan需要扫描的磁盘 DISK_PATH=/data/test.dd #dropScan时跳跃的数据块数量,数值越小覆盖磁盘越全面,速度越慢 BLOCK_INTERVAL=5
启用磁盘扫描操作
PDU.public=# p idxmode off;
┌─────────────────────────────────────────────────────────────────┐
│ 参数 │ 当前值 │
├─────────────────────────────────────────────────────────────────┤
│ startwal │ │
│ endwal │ │
│ startlsnt │ │
│ endlsnt │ │
│ starttime │ │
│ endtime │ │
│ resmode(Data Restore Mode) │ TIME │
│ exmode(Data Export Mode) │ CSV │
│ encoding │ UTF8 │
│ restype(Data Restore Type) │ DELETE │
----------------------DropScan----------------------
│ dsoff(DropScan startOffset) │ 0 │
│ blkiter(Block Intervals) │ 5 │
│ itmpcsv(Items Per Csv) │ 100 │
│ idxmode │ off │
└─────────────────────────────────────────────────────────────────┘
PDU.public=# ds;
▌全量扫描恢复模式
▌数据文件扫描
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
表名 │ 结果
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
PeisInterfaceLog 99.976 %(21469593600) 数据页: 71158 成功: 722947 (疑似乱码: 2809 ) 失败: 0
耗时 15.28 秒
└────────────────────────────────────────────────────────────────────────────────────────────────────┘
扫描完毕,文件目录如下:
restore/dropscan/PeisInterfaceLog
PDU.public=# ds copy;
已导出:
/restore/dropscan/PeisInterfaceLog/COPY.sql
PDU.public=#
[root@xifenfei PeisInterfaceLog]# more COPY.sql
[root@xifenfei PeisInterfaceLog]# cat /restore/dropscan/PeisInterfaceLog/COPY.sql
COPY PeisInterfaceLog FROM '/restore/dropscan/PeisInterfaceLog/09-28-21:29:55_226738176_32760blks_336787items.csv';
COPY PeisInterfaceLog FROM '/restore/dropscan/PeisInterfaceLog/09-28-21:30:01_595968000_32767blks_330416items.csv';
COPY PeisInterfaceLog FROM '/restore/dropscan/PeisInterfaceLog/09-28-21:30:04_1116061696_5631blks_55744items.csv';
把恢复数据导入到Postgres数据中
[root@xifenfei ~]# su - postgres [postgres@xifenfei ~]$ psql psql (12.8) Type "help" for help. postgres=# \i /restore/dropscan/PeisInterfaceLog/COPY.sql COPY 336787 COPY 330416 COPY 55744 postgres=# select count(1) from "PeisInterfaceLog"; count -------- 722947 (1 row)
经过上述扫描测试证明该工具实现了在Postgres中truncate数据的绝大部分数据恢复(这里的乱码不是由于没有扫描到数据,主要是由于个别字符串由于类型判断关系识别不对导致乱码抛弃).
如果你遇到Postgres 数据库由于drop/truncate等误操作,而且无有效备份进行恢复,面临数据丢失风险,请第一时间保护现场(数据文件所在分区尽可能不要有写入操作),联系我们提供专业恢复技术支持:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com

加我微信(17813235971)
加我QQ(107644445)

