Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

适用于:

Gen 2 Exadata Cloud at Customer
Oracle Database – Enterprise Edition – 版本 19.1.0.0.0 和更高版本
Oracle Database Cloud Exadata Service
Oracle Cloud Infrastructure – Exadata Cloud Service
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine)
本文档所含信息适用于所有平台
用途

本文档可用作手工将 Oracle 11gR2 (11.2) 或者 Oracle 12c Release 1 (12.1) 或者 Oracle 12c Release 2 (12.2) 版本数据库升级至 Oracle 19c 版本数据库的指南与核对表。

适用范围

数据库管理人员, 技术支持

详细信息

关于新的 Autoupgrade utility

Oracle 强烈建议使用 AutoUpgrade 工具来执行其他方法的数据库升级。
更多有关如何使用本工具的资料请参考 Note 2485457.1 and Oracle documentation

获取最新版本的 AutoUpgrade 工具,请参考 Note 2485457.1

Reference : AutoUprade Blog

步骤 1: 升级到数据库 19c 的升级路径

能够直接升级到 Oracle 19c 的数据库最小版本

升级矩阵
源数据库 目标数据库
11.2.0.4 19c
12.1.0.2 19c
12.2.0.1 19c
18.1 19c

以下的数据库版本需要间接升级

间接升级矩阵
源数据库 升级路径 目标数据库
12.1.0.1 –> 12.1.0.2/12.2.0.1 –> 19c
11.2.0.1/11.2.0.2/11.2.0.3 –> 11.2.0.4 –> 19c
11.1.0.6/11.1.0.7 –> 11.2.0.4 –> 19c
10.2.0.2, 10.2.0.3, 10.2.0.4, 10.2.0.5 –> 11.2.0.4/12.1.0.2 –> 19c
10.1.0.5 –> 11.2.0.4/12.1.0.2 –> 19c
9.2.0.8 或更低版本 –> 11.2.0.4 –> 19c

对于任何多步骤的升级,因为必须要升级两次,所以需要运行 preupgrade 脚本两次:首先,对于中间升级版本运行脚本一次,之后,对于最终升级到的版本运行脚本一次。比如,如果要升级的数据库是Oracle Database 10g,那么按照下面的步骤

  • 按照 Oracle Database Upgrade Guide 12c Release 1 (12.1) 的步骤升级 10.2.0.5 到 12.1.0.2,包括为 12.1.0.2 运行 pre-upgrade 脚本。
  • 直接升级 Oracle Database 12c release 1 (12.1.0.2) 到 Oracle Database 19c。按照Oracle Database Upgrade Guide的说明以及本文档,包括为 19c 运行 preupgrade 脚本。

如果您打算使用Data Pump export/import来升级,那么这个限制就不存在了。

比如:

  • 如果您要升级的数据库当前是 11.2.0.2 或者 11.1.0.7,那么您必须先要升级到 Oracle Database 11g release 2 (11.2.0.4)。
  • 如果您要升级的数据库当前是 10.2.0.2, 10.2.0.3, 10.2.0.4,10.2.0.5 或者 10.1.0.5,那么您先要升级到版本 11.2. 或者 12.1
  • 如果您要升级的数据库当前是 9.2.0.8, 那么您必须先要升级到一个中间版本:
  • 从 9.2.0.8 升级到 11.2.0.4,之后再从11.2升级到19c。

19c版本的变化

对 DBMS_JOB 的支持

Oracle继续支持DBMS_JOB包。但是,您必须赋予提交 DBMS_JOB jobs 的用户以 CREATE JOB 的权限。

Oracle Scheduler 替代了 DBMS_JOB package。尽管仍然支持 DBMS_JOB 以实现向后兼容,但 Oracle 强烈建议您从 DBMS_JOB 切换到 Oracle Scheduler。

  • 在DBMS_JOB中的每个作业的 19c 升级期间,将使用DBMS_SCHEDULER创建相应的条目
  • 旧的DBMS_JOB接口仍然有效。 但是使用它将总是在 scheduler 中创建相应的条目
  • preupgrade.jar 中的升级前检查会检查是否存在不一致或其它问题。

不再支持 Oracle Multimedia

Oracle Database 19c 中不再支持 Oracle Multimedia 功能,此功能已从 19c 中被移除。

作为图像处理和转换的替代方案,Oracle建议您将多媒体内容存储在 SecureFiles LOB 中,并且使用第三方产品,比如 Piction。 ORDIM 组件仍然可以在 registry 看到,并处于 VALID 状态。Oracle Multimedia 的对象和 packages 也仍然保留在数据库中。但是,这些对象和 packages 已不再起作用;如果尝试使用它们,则会引发异常。 Oracle Locator 不受 Oracle 多媒体支持的影响。

不再支持 Oracle Streams

从 Oracle Database 19c(19.1)开始,不再支持 Oracle Streams 功能。 Oracle GoldenGate 是 Oracle 数据库的复制解决方案。

请注意,Oracle Database Advanced Queuing 并未被弃用,Oracle Database 19c 完全支持 Oracle Database Advanced Queuing。 Oracle Streams 不支持 Oracle Database 12c (12.1) 及以后版本新加入的功能,比如 multitenant architecture, LONG VARCHAR, 以及其它功能。 Oracle Streams复制功能已被GoldenGate取代。

如果使用了 Oracle Streams,则 Preupgrade check “STREAMS_SETUP” 将发出警告。  要删除 Oracle Streams,则请参阅对应版本的 Oracle documentation,Oracle Streams Concepts and Administration Guide 中的 “Removing an Oracle Streams Configuration” 部分。

步骤2: 推荐/需要在源库上完成的

  • 对源库做备份,冷备份或热备份都可以。
  • 禁用所有自定义的 before/after DDL 类型的触发器,完成升级后再启用它们。
  • 在 11g 数据库上定义的 Data security roles 不能自动转换成 ORAS。 所以在升级前,需要删除所有在 11g 数据库上定义的 data security roles。升级后可以使用 Analytic Workspace Manager 19c 重新定义 data security roles。
  • 如果从 11g 升级到 19c 之前未删除 data security roles,那么所有的 data security policies 以及 data security role 都会在 19c 上失效。
  • 检查目标数据库的 time zone 文件版本是否低于源库的 time zone 文件版本,如果是的话,需要升级目标数据库的 time zone 文件版本。 数据库 DST 补丁可以参考  Note 412160.1
  • 如果源库上已经安装了 APEX 组件,那么 升级数据库前需要先在源库上升级 APEX 组件。参考 Note 1088970.1
  • 源库中没有失效的对象/组件
  • 升级前执行 Preupgrade 脚本并检查 preupgrade 日志。
  • 执行dbupgdiag.sql (可以从Note 556610.1 下载这个脚本) 确认是否有 SYS/SYSTEM 用户下的失效对象或者失效组件。 如果存在的话, 那么需要在升级前解决这些问题。 可以多次执行 utlrp.sql 来解决问题。如果在这样做之后仍然存在失效对象,那么开一个 SR 来解决这个问题。

步骤 3: 推荐/需要在目标库上完成的

  • 需要先检查您的硬件平台/操作系统是否兼容 19c.  点击  here 来确定兼容性。
  • 安装数据库软件 19c, 并确保没有安装方面的问题。
  • 如果有的话,下载并应用最新的 RU
  • 从源库的 ORACLE_HOME/dbs 下拷贝 spfile 或者 pfile 到目标库
    • 从参数文件中删除所有废弃的参数
    • 注意升级 19c 的 COMPATIBLE 参数的最小值为“11.2.0”, 确保您的 COMPATIBLE 参数设置为11.2.0或更高
  • 查看文章 “Patches to apply before upgrading Oracle GI and DB to 19c (Doc ID 2539751.1)”  中给出的补丁建议
  • 在目标库上应用 Patch 29213893 来避免已知问题。参考 Database Upgrade to 12.2, 18c, 19c fails with ORA-01422, ORA-06512 for SYS.DBMS_STATS (Doc ID 2525596.1)

步骤 4: 升级前检查

推荐在开始升级DB前先仔细完整的参考文档 Preparing to upgrade Oracle Database

清理数据库

清空回收站
检查 SYS 及 SYSTEM 用户的失效对象
检查 SYS 及 SYSTEM 用户下的重复对象
检查失效的、必需的、废弃的组件

注意: preupgrade.jar 也会提醒这些问题。

检查所有的物化视图

检查所有的物化视图的状态,刷新所有没有刷新的物化视图。
检查物化视图日志的大小,如果物化视图日志的行数非零,那么刷新物化视图。
检查 direct loader 日志以及 PMOP 日志(分区维护操作日志),如果 direct loader log 或者 PMOP 日志非空,那么刷新日志显示的物化视图。升级数据库前,必须确保所有的物化视图都已经刷新完毕。

执行下面的 SQL 查询:

SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;

注意:preupgrade.jar 也会提醒这些问题,请您注意检查 preupgrade 日志。

Schema-Only 的用户以及升级密码状态为 EXPIRED 的用户

在开始升级之前,请确定是否要对密码处于EXPIRED状态且其帐户处于LOCKED状态的默认Oracle数据库帐户使用密码身份验证。

在升级到 Oracle Database 19c 之后,默认的 Oracle 账号(没有设置密码并且处于 EXPIRED 和 LOCKED 状态)会被置为  NO AUTHENTICATION 状态。

由于此新功能,这些默认账号会变为 schema-only 帐户,并无法使用密码验证。此功能的好处是管理员不再需要定期修改这些Oracle默认账号的密码。

此功能还可以降低未授权者使用默认密码侵入这些帐户的安全风险。

如果要在升级期间阻止将这些Oracle帐户设置为仅 schema-only 帐户,则必须在开始升级之前为该帐户设置有效的强密码,或者在升级后为这些帐户设置有效的强密码, 或者在升级前解锁帐户。

升级后,管理员还可以为仅 schema-only 启用密码身份验证。 但是,为了更好的安全性,Oracle建议您将这些帐户保留为 schema-only 账号。

复制 Transparent Encryption Oracle 钱包

如果使用了带 Oracle 钱包的 Transparent Data Encryption (TDE),那么拷贝 thesqlnet.ora 和 wallet 文件到新的Oracle home。在升级前需要手工拷贝 sqlnet.ora 和 wallet 文件。

  1. 以授权用户身份登录。
  2. 手工拷贝 sqlnet.ora,wallet 文件以及 ewallet.p12,到新的 Oracle home。

打开数据库 wallet。

例如:

SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN

理解密码大小写敏感

从 Oracle Database 12c release 2 (12.2) 开始,默认的基于密码验证的协议排除了大小写不敏感的 10g 版本的密码。默认的SQLNET.ORA文件中参数SQLNET.ALLOWED_LOGON_VERSION_SERVER被设置成了 12 (排他模式)。

为了安全起见,Oracle建议使用大小写敏感的密码验证。这是默认的设置。但是在升级数据库的时候可以短暂的关闭大小写敏感的密码验证。在升级后,可以再决定是否启用大小写敏感的密码验证。

在升级前,Oracle建议您检查是否新的密码验证会影响您的应用。可以做下面的检查:

  • 检查是否有用户使用了 10g 大小写不敏感的密码验证方式。
  • 检查是否使用了尚未安装 CPUOct2012 补丁的11.2.0.3或者更早版本的客户端,或者应用了这个补丁但尚未启用大小写敏感的密码版本。
  • 确认您并未设置SEC_CASE_SENSITIVE_LOGON成FALSE。设置SEC_CASE_SENSITIVE_LOGON为FALSE就无法启用大小写敏感的密码版本了(11G和12C的密码版本)

更多信息请参考 19c Oracle database documentation

检查 密码大小写不敏感 的账号

确定要升级的Oracle数据库是否存在使用了不区分大小写密码版本的帐户。

从 Oracle Database 12c release 2 (12.2) 开始,默认的基于密码验证的协议排除了大小写不敏感的 10g 版本的密码。

如果未将 SQLNET.ALLOWED_LOGON_VERSION_SERVER 设置为允许不区分密码大小写版本的协议,并且您不希望将使用不区分大小写的密码版本进行身份验证的用户帐户锁定在数据库之外,那么您必须识别受影响的帐户,并确保他们使用区分大小写的密码版本。

更多信息请参考 19c Oracle database documentation

对只读表空间升级

以 -T 参数使用 Parallel Upgrade Utility 可以在升级时把用户表空间置为只读。 因为数据库可以读取之前版本创建的数据文件 header, 所以在升级时我们不需要做额外的操作。当升级完成后,表空间被置为读写时,文件 header 会自动被更新。如果升级失败,无法把表空间重新 online,那么检查升级日志。日志中包含把表空间重新 online 的语句。可以在数据库中或者每个pdb里手工执行来 online 表空间。

在升级日志文件中找到表空间相关的命令

如果升级失败可以检查升级的日志  (Oracle_base/cfgtoologs/dbua), 并且手工执行日志中的命令来 online 表空间。可以检查如下日志:

Non-CDB 升级: catupgrd0.log
PDB 数据库: catupgrdpdbname0.log, 这里 pdbname 是要升级的 pdb 的名字。

在每个日志文件的开始部分,可以找到把表空间置为只读的命令:

SQL> ALTER TABLESPACE <Tablespace Name> READ ONLY;
Tablespace altered.

而在每个日志文件的结尾部分,可以找到把表空间置为读写的SQL命令:

SQL> ALTER TABLESPACE <Tablespace Name> READ WRITE;
Tablespace altered.

为升级新的Oracle Home做准备

  • 从要升级的数据库 Home 拷贝配置文件到新的版本的Oracle Home中。
  • 如果您有一个 password 文件,那么把它从旧的 Oracle home 拷贝到新的 Oracle home。推荐重建 password 文件以利用 orapwd 的新功能,如果有的话。
  • 从参数文件中删除所有废弃的参数。在新的版本的数据库里有一些参数已经被废弃。从要启动新版本的数据库的参数文件中删除所有被废弃的参数,否则会在启动时产生错误。同时,修改那些在新版本里格式已经被改变的参数。
  • 如果要升级的是集群数据库,那么需要在升级前修改参数 CLUSTER_DATABASE 为 FALSE。

在Windows平台为升级新的Oracle Home做准备

在 Microsoft Windows 平台升级数据库前需要先确保系统已经满足升级条件。

出于安全考虑,不同的 Windows 账户配置为 Oracle home 不允许共享同一个 Oracle Base。

  • 当源库和目标库的 Oracle home 使用同一个 Windows 账户作为 oracle home 用户,数据库升级是支持的。
  • 数据库升级对于源数据库使用 Windows 自带账户是支持的。Oracle Database 12c 之前的版本 (release 11.2 或者之前的版本) 在 Windows 上只支持使用 Windows 自带的用户来作为 Oracle Home 用户。
  • Oracle home 用户可能没有权限访问自己的 Oracle Base 和 Oracle home 之外的文件。因此,如果您的升级使用不同的 Oracle Base,Oracle 数据库服务可能没有权限访问旧的 Oracle Base 下的文件。 使用DBUA进行数据库升级需要确保Oracle主用户可以访问其自己的Oracle Base及其自己的Oracle主目录之外的文件。
  • 在手工升级或者在需要访问旧的Oracle Base之外的文件(比如,wallets, 配置文件及其它文件)之前,需要确保 Oracle Home 用户可以访问这些文件;或者拷贝这些文件到新的 Oracle Base。

使用了 Oracle Label Security 和 Oracle Database Vault 的数据库

Audit Table升级及归档的要求

如果要升级的源库版本低于12.1并且安装了 Oracle Label Security和Oracle Database Vault,那么必须运行 OLS preprocess olspreupgrade.sql 脚本。

如果要升级使用了 Oracle Label Security (OLS) 和 Oracle Database Vault 的低于 12.1 版本的数据库,必须运行 OLS preprocess 脚本, olspreupgrade.sql,来处理 aud$ 表的内容。它会把 AUD$ 从 SYSTEM 用户迁移到 SYS 用户下。

如果要升级的数据库低于12.1,并且使用了 Oracle Label Security (OLS) 和 Oracle Database Vault,那么在升级前运行 olspreupgrade.sql 是必须的。一旦数据库升级到了12.1,那么就不需要执行OLS preprocessing 步骤了。

olspreupgrade.sql 脚本会在 SYS 用户下创建临时的表PREUPG_AUD$,并把 SYSTEM.AUD$ 的记录移到 SYS.PREUPG_AUD$。安全起见,Oracle推荐您在运行 olspreupgrade.sql 前归档您的审计记录。

升级前在 11.2 数据库上执行 OLS preprocess 脚本:

如果要升级的数据库安装有 Oracle Label Security,那么赋予SYS以DV_PATCH_ADMIN的角色

升级前在 11.2 数据库上执行 OLS preprocess 脚本:

1.    从 19c 的 Oracle Home 下拷贝以下脚本到源库的 Oracle Home(11.2) 下。

ORACLE_HOME/rdbms/admin/olspreupgrade.sql
ORACLE_HOME/rdbms/admin/emremove.sql
ORACLE_HOME/olap/admin/catnoamd.sql
2.    启动 SQL*Plus 并以 DVOWNER 登录到要升级的数据库。

3.    执行下面的SQL:

SQL> GRANT DV_PATCH_ADMIN to SYS;
4.    使用 SYS as SYSDBA 登陆数据库:

CONNECT SYS AS SYSDBA
5.    执行 Data Vault preprocess 脚本:

ORACLE_HOME/rdbms/admin/olspreupgrade.sql
ORACLE_HOME/rdbms/admin/emremove.sql
ORACLE_HOME/olap/admin/catnoamd.sql

6.    执行完毕后,以 DVOWNER 登陆数据库

7.    执行下面的SQL:

SQL> REVOKE DV_PATCH_ADMIN from SYS;

对于Database Vault,赋予SYS以DV_PATCH_ADMIN的角色

如果启用了Database Vault,那么也需要做对应的检查,检查步骤需要执行下面的SQL脚本 – olspreupgrade.sql, emremove.sql, catnoamd.sql

以 DVOWNER 登陆要升级的数据库

执行下面的SQL:

SQL> GRANT DV_PATCH_ADMIN to SYS;

使用 emremove.sql 手工删除 DB control

关闭 DB control

emctl stop dbconsole
使用 sysdba 登陆

SQL>SET ECHO ON
SQL>SET SERVEROUTPUT ON
SQL>@emremove.sql >> Script located in new 12c ORACLE_HOME/rdbms/admin

从系统中手工删除ORACLE_HOME/HOSTNAME_SID/ 和 ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID 目录
如果是 windows 系统则删除 DB Console 的系统服务 OracleDBConsoleSID

确保升级前所有的文件都没有处于备份模式

执行下面的语句:

SQL> SELECT * FROM v$backup WHERE status != ‘NOT ACTIVE’;

清空回收站

要清空回收站,执行下面的语句:

SQL> PURGE DBA_RECYCLEBIN

注意: 升级前务必清空回收站来避免 ORA-00600 错误并且减少升级时间。

性能方面

保存性能相关指标
检查网络性能
收集优化器统计信息

收集统计信息可以减少停机时间,Oracle建议使用  DBMS_STATS.GATHER_DICTIONARY_STATS 来收集这些统计信息,比如:

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

检查时区设置

源库的 time zone 文件版本应该小于或者等于目标库的 time zone 文件版本。如果源库的 time zone 文件版本更高,那么需要升级目标库的 time zone 文件版本来对应源库的 time zone 文件。

关于升级 Oracle OLAP Data Security Policies

在 11g 数据库上定义的 Data security roles 不能自动转换成 ORAS。所以在升级前,需要删除所有在 11g 数据库上定义的 data security roles。升级后可以使用新版本的 Analytic Workspace Manager 重新定义 data security roles。

如果从 11g 升级到 12c 之前未删除 data security roles,那么所有的 data security policies 以及 data security role 都会在新版本上失效。

Block Change Tracking

如果启用了 “Block Change Tracking” 功能,那么需要在升级前禁用它。下面是具体的命令

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

在升级前的源库执行上面的命令

在完成升级后再启用这个功能并在恢复增量备份前做一个0级备份。关于备份相关的信息请参照Oracle Backup and Recovery User’s Guide。另外,如果使用了手工内存管理,则请 一并参考文档<Doc ID 2651237.1>

PUBLIC Synonym AREA

如果安装了 Oracle Multimedia 或者 Oracle Spatial,在安装前检查 PUBLIC synonym AREA。它应当被定义为 OGC_AREA 的同义词,否则会导致升级后一些DB组件是失效的状态

SQL> select owner, synonym_name, table_owner, table_name from dba_synonyms where synonym_name = ‘AREA’;

OWNER         SYNONYM_NAME TABLE_OWNER TABLE_NAME
———— ——————– ————— ——————–
PUBLIC         AREA                    MDSYS            OGC_AREA

步骤 5: Preupgrade 步骤

在源库执行 Preupgrade 脚本

$Earlier_release_Oracle_home/jdk/bin/java -jar $New_release_Oracle_home/rdbms/admin/preupgrade.jar FILE TEXT DIR output_dir

FILE – 使用这个参数把输出写入输出文件
TEXT – 使用这个参数指定日志格式为 TEXT 模式(如果不指定的话则为 XML 格式)
DIR – 日志会创建在<output_dir>指定的这个目录中

注意: 您可以从此文档中下载最新的 preupgrade 脚本 - How to Download and Run Oracle’s Database Pre-Upgrade Utility (Doc ID 884522.1)

Pre-Upgrade 工具 (preupgrade.jar) 会创建以下的文件:

日志文件 preupgrade.log.
preupgrade_fixups_pdbname.sql (使用 PDBs 的情况下,这里 pdbname 就是 PDB 的名字) 或者 preupgrade_fixups.sql 脚本 (Non-CDB databases).
postupgrade_fixups_pdbname.sql (使用 PDBs 的情况下,这里 pdbname 就是 PDB 的名字) 或者 postupgrade_fixups.sql 脚本 (Non-CDB databases)。升级完成后执行这个脚本。

推荐执行 pre-upgrade fixup 脚本

Preupgrade fixup 脚本

在升级开始前,在SQL*Plus中手工执行 preupgrade fixups (preupgrade_fixups.sql) 脚本来解决 preupgrade tool 发现的问题。

Network Utility 包的依赖关系

执行 preupgrade 脚本后,检查 preupgrade 日志

WARNING: –> Database contains schemas with objects dependent on network packages.

…. Refer to the Database Upgrade Guide for instructions to configure Network ACLs.

…. USER WKSYS has dependent objects.

…. USER SYSMAN has dependent objects.

…. USER FLOWS_010600 has dependent objects.

执行下面的语句

SQL> SELECT * FROM DBA_DEPENDENCIES WHERE referenced_name IN (‘UTL_TCP’,’UTL_SMTP’,’UTL_MAIL’,’UTL_HTTP’,’UTL_INADDR’,’DBMS_LDAP’) AND owner NOT IN (‘SYS’,’PUBLIC’,’ORDPLUGINS’);

在升级测试中,确保使用新的访问控制。在升级后确保这些包是可用的,在升级后,根据源库的使用情况赋予正确的权限。

检查 Time zone 文件版本

检查目标数据库的 time zone 文件版本是否低于源库的 time zone 文件版本,如果是的话,需要升级目标数据库的 time zone 文件版本。  数据库 DST 补丁可以从  Note 412160.1 下载。

备份数据库

建议在运行 Pre-Upgrade Information Tool 之后备份数据库。创建 guaranteed flashback restore point。  测试备份,确保出现问题后有回退方案。

rman “target / nocatalog”

RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT ‘some_backup_directory%U’ TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT ‘controlfile location and name’;
}

备份文件以保留降级和恢复选项

Oracle Data Guard Broker配置文件和降级

升级到Oracle Database 19c及更高版本后,要保留降级到早期版本的功能,必须备份Data Guard broker 配置文件。

在Oracle Database 19c之前的版本中,Oracle Data Guard broker 的属性在Oracle Data Guard broker 配置文件中维护,并且可以使用DGMGRL 命令进行修改。 但是,从Oracle Database 19c开始,这些数据库设置不再存储在 broker 配置文件中。 作为此更改的结果,尽管您可以继续使用DGMGRL修改这些属性,但您修改的值不再存储在Oracle Data Guard broker 配置文件中。 相反,DGMGRL命令直接修改这些Oracle Data Guard Broker 属性映射到的Oracle数据库初始化参数。

由于对属性设置的管理方式进行了此更改,因此,如果使用Oracle Data Guard broker,则Oracle建议您在开始升级之前将早期版本的Oracle Data Guard broker 配置文件导出到安全的备份位置。 如果在升级之前未备份Oracle Data Guard broker配置文件,则在升级之后,您无法降级到早期版本并保留先前为Oracle Data Guard选择的属性设置。

导出 Broker 配置

使用 EXPORT CONFIGURATION 命令把 broker 配置信息的元数据导出到一个文本文件中。

Oracle 进程必须可以访问存储 broker 配置文件的目录。

连接到 primary 数据库。

DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected to “North_Sales”
Connected as SYSDG.
Export the broker configuration.

以下命令导出 broker  配置并将其存储在 trace 目录中名为myconfig.txt的文件中。

DGMGRL> EXPORT CONFIGURATION TO ‘myconfig.txt’;
Succeeded.

注意:这仅适用于19c或者更高版本的数据库

步骤 6: 升级数据库到 19c

关闭数据库

SQL> SHUTDOWN IMMEDIATE

Windows平台的步骤 :

如果操作系统是Windows,那么完成下面的步骤:

a. 停掉要升级的数据库 OracleServiceSID Oracle service,这里的SID是实例名。比如,如果SID是ORCL,那么执行下面的命令:

C:\> NET STOP OracleServiceORCL

b. 使用ORADIM来删除 Oracle service。请参考平台相关的文档来获取ORADIM命令的格式。比如,如果您的SID是ORCL,那么执行下面的命令

C:\> ORADIM -DELETE -SID ORCL

c. 使用新ORACLE软件的ORADIM来创建 service。
比如:

C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS  -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

对于 Unix/Linux

设置环境变量指向目标 ORACLE_HOME

export ORACLE_HOME=<path to Oracle 19c>
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_BASE=<path to Oracle_Base set during installation>

从旧的Oracle home下拷贝 SPFILE.ORA 或者 INIT.ORA到目标Oracle home

使用目标 ORACLE_HOME(设置 ORACLE_HOME 为目标 ORACLE_HOME)启动数据库到 upgrade 模式

CONNECT / AS SYSDBA
SQL> startup upgrade;
SQL> exit

在 Linux/Unix 上

cd $ORACLE_HOME/bin
./dbupgrade

在 Windows 上

cd %ORACLE_HOME%\bin
dbupgrade

执行 Post-Upgrade Status 工具, utlusts.sql 并且检查升级的日志。在新的版本下执行 Post-Upgrade Status 工具。

$ sqlplus “/as sysdba”
SQL> STARTUP
SQL> @?ORACLE_HOME/rdbms/admin/utlusts.sql

注意: 之前版本的 utluNNNs.sql 在 19c 上被替换为 utlusts.sql

注意: 如果执行 utlusts.sql 时碰到错误 “ORA-06502: PL/SQL: numeric or value error: character string buffer too small” ,那么执行
$ sqlplus “/as sysdba”
SQL> STARTUP
SQL> @?ORACLE_HOME/rdbms/admin/utlusts.sql TEXT

如果使用了Oracle Clusterware,设置了 CLUSTER_DATABASE=TRUE 那么你必须升级数据库对应的 Oracle Clusterware keys。在19c上运行 srvctl 来做这件事,比如:

ORACLE_HOME/bin/srvctl upgrade database -db name -o ORACLE_HOME

检查升级状态

执行 dbupgdiag.sql 并检查日志。可以从 Note 556610.1 下载这个脚本。

编译失效对象

执行 utlrp.sql (多次) 来使它们生效,直到失效对象的个数不再改变。

$ sqlplus “/ AS SYSDBA”
SQL> @Oracle_home/rdbms/admin/utlrp.sql

步骤7: 升级后步骤

在 Linux 和 Unix 上设置环境变量

确保下面的环境变量指向了新的 ORACLE_HOME 对应的目录:

ORACLE_HOME
PATH

更新 oratab 文件

修改 /etc/oratab 文件对应的条目指向新的 ORACLE_HOME 目录

Post-upgrade fixup 脚本

执行 pre-upgrade 产生的 post-upgrade fixup 脚本

SQL> @postupgrade_fixups.sql

使用 ORAPWD 创建或者迁移您的密码文件

如果REMOTE_LOGIN_PASSWORDFILE初始化参数设置为EXCLUSIVE,则使用ORAPWD创建或迁移密码文件。 Oracle Database 12c及更高版本为ORAPWD提供了一个新选项,用于从现有数据库迁移密码文件。

对于Oracle Database 12c第2版(12.2)及更高版本,如果REMOTE_LOGIN_PASSWORDFILE设置为SHARED,则会收到升级前检查验证警告。 您可以选择以下选项之一来解决此问题:

通过设置REMOTE_LOGIN_PASSWORDFILE = NONE完全禁用基于密码文件的身份验证

通过设置REMOTE_LOGIN_PASSWORD = EXCLUSIVE限制基于密码文件的身份验证

在升级数据库后升级 Recovery Catalog

如果使用的recovery catalog版本低于rman客户端的版本,我们必须升级它。可以通过命令 UPGRADE CATALOG 来升级 Recovery catalog。

关于具体的步骤信息,请参照Oracle文档中的 Upgrading the Recovery Catalog。

在升级数据库后升级 Time Zone文件版本

如果 Pre-Upgrade Information Tool 要求我们在升级数据库后升级 time zone 文件,那么使用 DBMS_DST PL/SQL package 来升级 RDBMS DST(timezone)版本

以下脚本随Oracle Database 18c及以上版本一起提供

$ORACLE_HOME/rdbms/admin/utltz_countstats.sql
脚本使用统计信息提供在数据库中TIMESTAMP WITH TIME ZONE数据的数量。 无需重启。

$ORACLE_HOME/rdbms/admin/utltz_countstar.sql
脚本使用COUNT(*)查询每个具有TSTZ列的表来计算数据库中的TIMESTAMP WITH TIME ZONE数据的数量。 使用DBMS_DST包或utlz_upg_check.sql和utlz_upg_apply.sql脚本时,此脚本非常有用。

$ORACLE_HOME/rdbms/admin/utltz_upg_check.sql
时区升级检查脚本

?/rdbms/admin/utltz_upg_apply.sql
时区应用脚本。 警告:此脚本将重新启动数据库并调整时区数据。

升级那些使用 DBMS_STATS 创建的统计信息表(Statistics Tables)

如果我们使用 DBMS_STATS.CREATE_STAT_TABLE 手工创建了一些统计信息表(statistics tables),那么执行下面的命令来升级这些表(如果没有创建过统计信息表,那这一步骤可以忽略)。例如:

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE(‘SYS’, ‘dictstattab’);

对每个统计信息表都要执行一遍上面的命令。

参考:Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单 (Doc ID 2577572.1)

sqlite数据库简单操作

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:sqlite数据库简单操作

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

sqlite创建库并创建表插入数据

E:\RECOVER\sqllite>sqlite3
SQLite version 3.48.0 2025-01-14 11:05:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.db
sqlite> create table t1(id int)
   ...> ;
sqlite> insert into t1 values(1);
sqlite> insert into t1 values(2);
sqlite> insert into t1 values(23;
sqlite> insert into t1 values(23);
sqlite> select * from t1;
1
2
23

sqlite> .q

sqlite导出数据(在sqlite库部分有损坏的情况下也可以导出)

E:\RECOVER\sqllite>sqlite3
SQLite version 3.48.0 2025-01-14 11:05:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.db
sqlite> select * from t1;
1
2
23
sqlite> .mode insert
sqlite> .output dbdump.sql
sqlite> .dump
sqlite> .exit

E:\RECOVER\sqllite>

sqlite导入数据

E:\RECOVER\sqllite>sqlite3
SQLite version 3.48.0 2025-01-14 11:05:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test2.db
sqlite> .read dbdump.sql
sqlite> select * from t1;
1
2
23
sqlite> .exit

E:\RECOVER\sqllite>

对于损坏的sqlite数据库也可以采用此方法进行尝试

Oracle 暂定和恢复功能

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle 暂定和恢复功能

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

以前一直没有注意到oracle有暂定和恢复功能(SUSPEND/RESUME)[从oracle 8i开始有的特性],一下是官方描述:

The Database Suspend/Resume feature provides a mechanism by which all disk I/O 
(datafile, controlfile and file header I/Os) in a database (in all instances) 
can be suspended making it easier to make a copy of the database.  When an 
ALTER SYSTEM SUSPEND command is issued, it will wait for any ongoing instance 
recovery to complete and then set a flag in all running instances to stop all 
new lock and I/O activity.  The command may return before the last I/O is 
issued because the check for the flag might have been before the suspend and 
the I/O might have been issued after the suspend.  So, reads, typically are not
allowed when the database is suspended but may still be active for a period of 
time.  However, this command does ensure that no new I/Os will be issued.  

Once all instances of a database are suspended, a copy of the database can be 
made by making a copy of all the files (i.e. the control file, online logs and 
all data files).  The copy can have uncommitted updates and therefore the only 
way a copy of the database can be used in this scenerio is to do an instance 
recovery and then open it.

The database can be suspended or resumed through an ALTER SYSTEM call.  You can
issue this statement as the user SYSTEM or SYS (the user must have DBA 
privileges).   

The syntax for these two commands is as follows:

    ALTER SYSTEM <options>;

    <options> = SUSPEND | RESUME | <existing options>

The database will remain in the suspended state until the ALTER SYSTEM RESUME 
command is issued.  The database will remain suspended even if the process 
issuing the ALTER SYSTEM SUSPEND command dies or exists.  However, if all 
instances are shutdown and started again, the database is no longer in a 
suspended state.  

The ALTER SYSTEM RESUME command has the effect of blocking the I/O since the 
SUSPEND command.  When the RESUME command is issued, it might cause a burst in 
the I/O, which may take a while to even out.  A message is written to the alert
log everytime the database is suspended or resumed, as shown by the example 
below:

    Mon Nov 29 11:32:22 1999
    Completed: alter database open
    Wed Dec  1 12:56:53 1999
    Starting ORACLE instance (normal)
    Wed Dec  1 22:03:50 1999
    Suspending database following alter system suspend command.
    Wed Dec  1 22:06:14 1999
    Resuming database following alter system resume command.
    Wed Dec  1 22:07:08 1999


The following is an example of using the SUSPEND and RESUME feature:

    SVRMGR> connect system/manager
    Connected.
    SVRMGR> alter system suspend;
    Statement processed.
    SVRMGR> select * from user_source;
    ^X^Cselect * from user_source   -----  (at this stage the statement will 
                                            just hang.  A Ctrl-X Ctrl-C was 
                                            issued to kill the statement)
                  *
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01013: user requested cancel of current operation
    SVRMGR>
    SVRMGR> alter system resume;
    Statement processed.


Considerations and Restrictions:
--------------------------------
- The files in the copy database can not be used as backups of the original 
  database for media recovery.  (If the direct path option is in use at the 
  time, there may be corrupted blocks).

- A new instance cannot be started during the SUSPEND state of the database.  
  If one is started, it will not be included in the SUSPEND process and thus no 
  I/O suspension guarantees are provided in this case.

- Creation of backups or archived logs will not be affected by the 
  ALTER SYSTEM SUSPEND command.

- The two different commands can  be issued from two different instances or 
  processes.

- If the SUSPEND command during execution may fail for some reason yet 
  result in some of the instances being suspended, the command can be issued 
  again since the instances in suspend status will ignore the command.

- Also database queries will hang when the database is in suspend mode

按照描述SUSPEND 操作会挂起所有io,只要涉及到io操作就会挂起,如果操作的所有请求都可以在内存中完成(buffer cache/shared pool等),那这样的操作是可以直接完成的.

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Jan 14 21:51:53 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system suspend;

System altered.

SQL> select database_status from v$instance;

DATABASE_STATUS
-----------------
SUSPENDED

SQL> create table t1 as select * from dba_users;
create table t1 as select * from dba_users
             *
ERROR at line 1:
ORA-00955: name is already used by an existing object


SQL> create table t_xff as select * from dba_users;
^C
C:\Users\XFF>

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Jan 14 21:53:19 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system resume;

System altered.

SQL> select database_status from v$instance;

DATABASE_STATUS
-----------------
ACTIVE

SQL> create table t_xff as select * from dba_users;

Table created.


SQL>  alter system suspend;

System altered.

SQL> select count(1) from user$;

  COUNT(1)
----------
        94

SQL> select count(1) from t_xff;
^C
C:\Users\XFF>

在某些情况下,可以通过这类操作来挂起数据库,做一些特殊的操作.

.pzpq扩展名勒索恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.pzpq扩展名勒索恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有一个10g的库,数据库被勒索病毒加密扩展名为:.email=[biobiorans@gmail.com]id=[f5657ac3dc58dc8c].biobio.[backups@airmail.cc].pzpq
pzpq


#Read-for-recovery.txt文件中内容

Email 1: 
backups@airmail.cc

Email 2: 
hero77@cock.li

Send messages to both emails at the same time 

So send messages to our emails, check your spam folder every few hours 

ID: E3DxxxxxxxxxxxxxxxDBB73

If you do not receive a response from us after 24 hours, create a valid email, for example, gmail,outlook 
Then send us a message with a new email

通过底层对数据库block进行分析,确认损坏的block情况为,头部损坏16个block,中间16个block,尾部16个block
QQ20250113-214706


通过Oracle数据文件勒索加密恢复工具,实现快速恢复
QQ20250113-220625

然后尝试打开数据库报ORA-600 4193错误

un Jan 12 22:35:09 2025
ALTER DATABASE OPEN
Sun Jan 12 22:35:10 2025
Thread 1 opened at log sequence 4
  Current log# 3 seq# 4 mem# 0: D:\ORCL\REDO03.LOG
Successful open of redo thread 1
Sun Jan 12 22:35:10 2025
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Jan 12 22:35:10 2025
SMON: enabling cache recovery
Sun Jan 12 22:35:10 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\udump\norcl_ora_2796.trc:
ORA-00600: internal error code, arguments: [4193], [58], [52], [], [], [], [], []

Sun Jan 12 22:35:11 2025
Doing block recovery for file 1 block 404
Block recovery from logseq 4, block 73424 to scn 137439548723
Sun Jan 12 22:35:11 2025
Recovery of Online Redo Log: Thread 1 Group 3 Seq 4 Reading mem 0
  Mem# 0: D:\ORCL\REDO03.LOG
Block recovery stopped at EOT rba 4.73426.16
Block recovery completed at rba 4.73426.16, scn 32.595250
Doing block recovery for file 1 block 9
Block recovery from logseq 4, block 73424 to scn 137439548721
Sun Jan 12 22:35:11 2025
Recovery of Online Redo Log: Thread 1 Group 3 Seq 4 Reading mem 0
  Mem# 0: D:\ORCL\REDO03.LOG
Block recovery completed at rba 4.73426.16, scn 32.595250
Sun Jan 12 22:35:11 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\udump\norcl_ora_2796.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4193], [58], [52], [], [], [], [], []

Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Sun Jan 12 22:35:11 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_pmon_2168.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_reco_2688.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_smon_2332.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_ckpt_2600.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_lgwr_2672.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_dbw0_1344.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_mman_2828.trc:
ORA-00604: error occurred at recursive SQL level 

Sun Jan 12 22:35:12 2025
Errors in file d:\oracle\product\10.2.0.3\admin\orcl\bdump\norcl_psp0_2324.trc:
ORA-00604: error occurred at recursive SQL level 

Instance terminated by USER, pid = 2796
ORA-1092 signalled during: ALTER DATABASE OPEN...

通过分析trace,确认是系统回滚段的free block pool异常,使用bbed进行修复

BBED> clean free_block_pool
Clean free block pool completed.you can use dump to verify the data, then can us
e sum apply command to save data.
BBED> sum apply

Warning: apply the modified data will overwrite original data.
Would you like to continue? (y/n)
y

Old checksum value: 0xf2c0
New checksum value: 0xf315
Writing block has completed

BBED>

open数据库成功,然后安排导出数据即可
QQ20250113-222649


对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。

Oracle read only用户—23ai新特性:只读用户

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle read only用户—23ai新特性:只读用户

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

23ai版本支持用户级别设置read only特性,对于在某些情况下,为了数据的一致性,是一个比较方便的特性,而不是以前版本通过权限控制实现只读,比如授权create session+表/视图等查询权限
下面创建一个用户u_readonly,并授权dba权限,创建一个表进行测试

[oracle@xifenfei ~]$ ss

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Sat Jan 11 21:12:09 2025
Version 23.5.0.24.07

Copyright (c) 1982, 2024, Oracle.  All rights reserved.


Connected to:
Oracle Database 23ai Enterprise Edition Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.5.0.24.07

SQL> 
SQL> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 23ai Enterprise Edition Release 23.0.0.0.0 - for Oracle Cloud an
d Engineered Systems


SQL> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 XIFENFEI                       MOUNTED
SQL> alter session set container=xifenfei;

Session altered.

SQL> alter database open;

Database altered.

SQL> create user u_readonly identified by oracle;

User created.

SQL> grant dba to u_readonly;

Grant succeeded.

SQL>  conn u_readonly/oracle@127.0.0.1/xifenfei
Connected.
SQL> create table t_xff as select * from dba_objects;

Table created.

SQL> select count(1) from t_xff;

  COUNT(1)
----------
     70951

修改用户为只读特性,然后进行dml/ddl操作会报ORA-28194: Can perform read operations only

SQL> conn / as sysdba
Connected.
SQL>  alter session set container=xifenfei;

Session altered.

SQL> alter user u_readonly read only;

User altered.

SQL> conn u_readonly/oracle@127.0.0.1/xifenfei
Connected.
SQL> delete from t_xff;
delete from t_xff
            *
ERROR at line 1:
ORA-28194: Can perform read operations only


SQL> insert into t_xff select * from dba_objects;
insert into t_xff select * from dba_objects
            *
ERROR at line 1:
ORA-28194: Can perform read operations only


SQL> select count(1) from t_xff;

  COUNT(1)
----------
     70951

SQL> create table t1 as select * from dba_users;
create table t1 as select * from dba_users
*
ERROR at line 1:
ORA-28194: Can perform read operations only

直接使用create user命令创建一个只读用户

SQL>  conn / as sysdba
Connected.
SQL> alter session set container=xifenfei;

Session altered.

SQL> create user u_readonly2 identified by oracle read only;

User created.

SQL> grant dba to u_readonly2;

Grant succeeded.

SQL>  conn u_readonly2/oracle@127.0.0.1/xifenfei
Connected.
SQL> create table t_xifenfei as select * from dba_objects;
create table t_xifenfei as select * from dba_objects
*
ERROR at line 1:
ORA-28194: Can perform read operations only

修改只读用户为读写模式

SQL> conn / as sysdba
Connected.
SQL>  alter session set container=xifenfei;

Session altered.

SQL> alter user u_readonly2 read write;

User altered.

SQL> conn u_readonly2/oracle@127.0.0.1/xifenfei
Connected.
SQL> create table t_xifenfei as select * from dba_objects;

Table created.

SQL> delete from t_xifenfei where rownum<100;

99 rows deleted.

SQL> commit;

Commit complete.

查看用户是否处于只读状态

SQL> select username,read_only from dba_users  where created>sysdate-1;

USERNAME                       READ_O
------------------------------ ------
U_READONLY2                    NO
U_READONLY                     YES

在只读用户中,使用动态plsql直接直接dml也报ORA-28194: Can perform read operations only

SQL> conn u_readonly/oracle@127.0.0.1/xifenfei
Connected.
SQL> select count(1) from t_xff;

  COUNT(1)
----------
     70951

SQL> delete from t_xff;
delete from t_xff
            *
ERROR at line 1:
ORA-28194: Can perform read operations only


SQL> DECLARE   
  2      v_sql VARCHAR2(1000);
  3  BEGIN
  4      v_sql := 'delete from t_xff where rownum<1000';
  5      EXECUTE IMMEDIATE v_sql;
  6  END;
  7  /
DECLARE
*
ERROR at line 1:
ORA-28194: Can perform read operations only
ORA-06512: at line 5

判断用户是否只读的底层基表属性user$.spare1

SQL> conn / as sysdba
Connected.
SQL> alter session set container=xifenfei;

Session altered.
SQL> COL NAME FOR A30
SQL>  select name,decode(bitand(spare1, 67108864), 67108864, 'YES', 'NO')
  2   read_only from user$ where name like 'U_READONLY%'
  3  /

NAME                           READ_O
------------------------------ ------
U_READONLY                     YES
U_READONLY2                    NO

迁移awr快照数据到自定义表空间

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:迁移awr快照数据到自定义表空间

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在19c中有些情况,考虑把awr的快照数据存储在非sysaux表空间,可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS来进行设置

sys@ORA19C 21:57:02> select BANNER_FULL from v$version;

BANNER_FULL
----------------------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.24.0.0.0


Elapsed: 00:00:00.01

PROCEDURE MODIFY_SNAPSHOT_SETTINGS
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RETENTION                      NUMBER                  IN     DEFAULT
 INTERVAL                       NUMBER                  IN     DEFAULT
 TOPNSQL                        NUMBER                  IN     DEFAULT
 DBID                           NUMBER                  IN     DEFAULT
 TABLESPACE_NAME                VARCHAR2                IN     DEFAULT
PROCEDURE MODIFY_SNAPSHOT_SETTINGS
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 RETENTION                      NUMBER                  IN     DEFAULT
 INTERVAL                       NUMBER                  IN     DEFAULT
 TOPNSQL                        VARCHAR2                IN
 DBID                           NUMBER                  IN     DEFAULT
 TABLESPACE_NAME                VARCHAR2                IN     DEFAULT

这两个proc,主要是TOPNSQL一个是number类型,一个是varchar2类型
If NUMBER: Top N SQL size. The number of Top SQL to flush for each SQL criteria (Elapsed Time, CPU Time, Parse Calls, Shareable Memory, Version Count). The value for this setting will not be affected by the statistics/flush level and will override the system default behavior for the AWR SQL collection. The setting will have a minimum value of 30 and a maximum value of 50,000. Specifying NULL will keep the current setting.
If VARCHAR2: Users are allowed to specify the following values: (DEFAULT, MAXIMUM, N), where N is the number of Top SQL to flush for each SQL criteria. Specifying DEFAULT will revert the system back to the default behavior of Top 30 for statistics level TYPICAL and Top 100 for statistics level ALL. Specifying MAXIMUM will cause the system to capture the complete set of SQL in the cursor cache. Specifying the number N is equivalent to setting the Top N SQL with the NUMBER type. Specifying NULL for this argument will keep the current setting.
进行了简单的测试,确认是部分awr的分区表设置到新表空间中

sys@ORA19C 21:41:51> CREATE TABLESPACE AWRTBS DATAFILE '/data/oradata/ORA19C/awrtbs01.dbf' size 128M autoextend on;

Tablespace created.

Elapsed: 00:00:00.53
sys@ORA19C 21:42:21> exec dbms_workload_repository.modify_snapshot_settings(tablespace_name=> 'AWRTBS');

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.53

sys@ORA19C 21:53:56> execute dbms_workload_repository.create_snapshot();

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.44
sys@ORA19C 21:53:58> select segment_name,PARTITION_NAME,segment_type from dba_segments where tablespace_name='AWRTBS';

SEGMENT_NAME                   PARTITION_NAME                                               SEGMENT_TYPE
------------------------------ ------------------------------------------------------------ ---------------
WRH$_FILESTATXS                WRH$_FILESTATXS_1232450071_2690                              TABLE PARTITION
WRH$_SQLSTAT                   WRH$_SQLSTAT_1232450071_2690                                 TABLE PARTITION
WRH$_SYSTEM_EVENT              WRH$_SYSTEM_EVENT_1232450071_2690                            TABLE PARTITION
WRH$_WAITSTAT                  WRH$_WAITSTAT_1232450071_2690                                TABLE PARTITION
WRH$_LATCH                     WRH$_LATCH_1232450071_2690                                   TABLE PARTITION
WRH$_LATCH_MISSES_SUMMARY      WRH$_LATCH_MISSES_SUMMARY_1232450071_2690                    TABLE PARTITION
WRH$_DB_CACHE_ADVICE           WRH$_DB_CACHE_ADVICE_1232450071_2690                         TABLE PARTITION
WRH$_ROWCACHE_SUMMARY          WRH$_ROWCACHE_SUMMARY_1232450071_2690                        TABLE PARTITION
WRH$_SGASTAT                   WRH$_SGASTAT_1232450071_2690                                 TABLE PARTITION
WRH$_SYSSTAT                   WRH$_SYSSTAT_1232450071_2690                                 TABLE PARTITION
WRH$_PARAMETER                 WRH$_PARAMETER_1232450071_2690                               TABLE PARTITION
WRH$_SEG_STAT                  WRH$_SEG_STAT_1232450071_2690                                TABLE PARTITION
WRH$_SERVICE_STAT              WRH$_SERVICE_STAT_1232450071_2690                            TABLE PARTITION
WRH$_ACTIVE_SESSION_HISTORY    WRH$_ACTIVE_SESSION_HISTORY_1232450071_2690                  TABLE PARTITION
WRH$_SYSMETRIC_HISTORY         WRH$_SYSMETRIC_HISTORY_1232450071_2690                       TABLE PARTITION
WRH$_LATCH_CHILDREN            WRH$_LATCH_CHILDREN_1232450071_0                             TABLE PARTITION
WRH$_LATCH_PARENT              WRH$_LATCH_PARENT_1232450071_0                               TABLE PARTITION
WRH$_DLM_MISC                  WRH$_DLM_MISC_1232450071_0                                   TABLE PARTITION
WRH$_INST_CACHE_TRANSFER       WRH$_INST_CACHE_TRANSFER_1232450071_0                        TABLE PARTITION
WRH$_INTERCONNECT_PINGS        WRH$_INTERCONNECT_PINGS_1232450071_0                         TABLE PARTITION
WRH$_TABLESPACE_STAT           WRH$_TABLESPACE_STAT_1232450071_2690                         TABLE PARTITION
WRH$_OSSTAT                    WRH$_OSSTAT_1232450071_2690                                  TABLE PARTITION
WRH$_SYS_TIME_MODEL            WRH$_SYS_TIME_MODEL_1232450071_2690                          TABLE PARTITION
WRH$_SERVICE_WAIT_CLASS        WRH$_SERVICE_WAIT_CLASS_1232450071_2690                      TABLE PARTITION
WRH$_EVENT_HISTOGRAM           WRH$_EVENT_HISTOGRAM_1232450071_2690                         TABLE PARTITION
WRH$_MVPARAMETER               WRH$_MVPARAMETER_1232450071_2690                             TABLE PARTITION
WRH$_CELL_GLOBAL_SUMMARY       WRH$_CELL_GLOBAL_SUMMARY_1232450071_2690                     TABLE PARTITION
WRH$_CELL_DISK_SUMMARY         WRH$_CELL_DISK_SUMMARY_1232450071_2690                       TABLE PARTITION
WRH$_CELL_GLOBAL               WRH$_CELL_GLOBAL_1232450071_2690                             TABLE PARTITION
WRH$_CELL_IOREASON             WRH$_CELL_IOREASON_1232450071_2690                           TABLE PARTITION
WRH$_CELL_DB                   WRH$_CELL_DB_1232450071_2690                                 TABLE PARTITION
WRH$_CELL_OPEN_ALERTS          WRH$_CELL_OPEN_ALERTS_1232450071_2690                        TABLE PARTITION
WRH$_IM_SEG_STAT               WRH$_IM_SEG_STAT_1232450071_2690                             TABLE PARTITION
WRM$_PDB_IN_SNAP               WRM$_PDB_IN_SNAP_1232450071_2690                             TABLE PARTITION
WRH$_CON_SYSMETRIC_HISTORY     WRH$_CON_SYSMETRIC_HISTORY_1232450071_2690                   TABLE PARTITION
WRM$_ACTIVE_PDBS               WRM$_ACTIVE_PDBS_1232450071_2690                             TABLE PARTITION
WRH$_CON_SYSSTAT               WRH$_CON_SYSSTAT_1232450071_2690                             TABLE PARTITION
WRH$_CON_SYSTEM_EVENT          WRH$_CON_SYSTEM_EVENT_1232450071_2690                        TABLE PARTITION
WRH$_PROCESS_WAITTIME          WRH$_PROCESS_WAITTIME_1232450071_2690                        TABLE PARTITION
WRH$_ASM_DISK_STAT_SUMMARY     WRH$_ASM_DISK_STAT_SUMMARY_1232450071_2690                   TABLE PARTITION
WRH$_AWR_TEST_1                WRH$_AWR_TEST_1_1232450071_2690                              TABLE PARTITION
WRH$_SESS_NETWORK              WRH$_SESS_NETWORK_1232450071_2690                            TABLE PARTITION
WRH$_CON_SYS_TIME_MODEL        WRH$_CON_SYS_TIME_MODEL_1232450071_2690                      TABLE PARTITION

43 rows selected.

Elapsed: 00:00:00.01
sys@ORA19C 21:54:08> 

.hmallox加密mariadb/mysql数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.hmallox加密mariadb/mysql数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户运行在win机器上的mariadb数据库被勒索加密了,加密扩展名为.hmallox
hmallox


HOW TO BACK FILES.txt文件内容

Hello

Your data has been stolen and encrypted
We will delete the stolen data and help with the recovery of encrypted files after payment has been made

Do not try to change or restore files yourself, this will break them
We provide free decryption for any 3 files up to 3MB in size on our website

How to contact with us:
1) Download and install TOR browser by this link: https://www.torproject.org/download/
2) If TOR blocked in your country and you can't access to the link then use any VPN software
3) Run TOR browser and open the site: wtyafjyxxxxxxxxxxxxxxxxxxxxxxxxljoyuklaad.onion/mallox/privateSignin
4) Copy your private ID in the input field. Your Private key: D7xxxxxxxxxxxxxxx90
5) You will see chat, payment information and we can make free test decryption here

Our blog of leaked companies:

wtyafjyxxxxxxxxxxxxxxxxxxxxxxxxljoyuklaad.onion

If you are unable to contact us through the site, then you can email us: mallox.resurrection@onionmail.org
Waiting for a response via mail can be several days. Do not use it if you have not tried contacting through the site. 

通过分析,ibd文件情况尚可
ibd


对于这种情况,对于ibd文件进行分析结合客户提供的字典信息,完美恢复数据,业务直接使用

2025年首个故障恢复—ORA-600 kcbzib_kcrsds_1

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:2025年首个故障恢复—ORA-600 kcbzib_kcrsds_1

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

一个12.2.0.1的库由于某种原因引起的双机切换,导致数据库无法正常mount

2025-01-04T15:45:44.424193+08:00
alter database mount
2025-01-04T15:45:48.491054+08:00
Network throttle feature is disabled as mount time

2025-01-04T15:45:48.601366+08:00
LGWR (ospid: 34014): terminating the instance
2025-01-04T15:45:48.602480+08:00
System state dump requested by (instance=1, osid=34014 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/oracle/diag/rdbms/xifenfei/trace/xifenfei_diag_33978_20250104154548.trc
2025-01-04T15:45:48.790674+08:00
Dumping diagnostic data in directory=[cdmp_20250104154548], requested by (instance=1, osid=34014 (LGWR))
2025-01-04T15:45:49.915068+08:00
Instance terminated by LGWR, pid = 34014

这个错误相对比较明显,是由于ctl异常导致,通过重建ctl,然后mount库,利用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本进行检测发现所有数据文件头的checkpoint 信息被冻结在 2024-11-29 19:00:29 (scn 2112302221),分析alert日志数据库在此后20天中正常提供服务,业务运行都正常,客户反馈在这个冻结checkpoint信息的时间点,使用备份一体机发起过备份,之后就没有再备份了.
当时急着恢复数据库,没有对文件头进行dump不然应该可以发现类似begin backup的信息,类似这样(测试环境重现):

DATA FILE #1:
  name #7: /u01/app/oracle/oradata/xifenfei/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:625 scn: 0x0105.0106deef 01/04/2025 22:02:50
 Stop scn: 0xffff.ffffffff 12/14/2024 08:15:07
 Creation Checkpointed at scn:  0x0000.00000007 08/24/2013 11:37:33
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000
 Offline scn: 0x0000.000e2005 prev_range: 0
 Online Checkpointed at scn:  0x0000.000e2006 03/20/2024 20:53:56
 thread:1 rba:(0x1.2.0)
 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED
 Plugged readony: NO
 Plugin scnscn: 0x0000.00000000
 Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
 Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
 Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
 Online move state: 0
 V10 STYLE FILE HEADER:
        Compatibility Vsn = 186647552=0xb200400
        Db ID=1780931490=0x6a26dba2, Db Name='XIFENFEI'
        Activation ID=0=0x0
        Control Seq=32953021=0x1f6d2bd, File size=98560=0x18100
        File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM  rel_fn:1
Creation   at   scn: 0x0000.00000007 08/24/2013 11:37:33
Backup taken at scn: 0x0105.0106deef 01/04/2025 22:02:50 thread:1    <====注意
 reset logs count:0x45636764 scn: 0x0000.000e2006
 prev reset logs count:0x3121c97a scn: 0x0000.00000001
 recovered at 12/14/2024 08:36:35
 status:0x2001 root dba:0x00400208 chkpt cnt: 625 ctl cnt:624
begin-hot-backup file size: 98560                        <====注意
Checkpointed at scn:  0x0105.0106deef 01/04/2025 22:02:50
 thread:1 rba:(0x205.fdd9.10)
 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000
Backup Checkpointed at scn:  0x0105.0106df14 01/04/2025 22:03:20   <====注意
 thread:1 rba:(0x209.2.10)
 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp  01/01/1988 00:00:00
Platform Information:    Creation Platform ID: 13
Current Platform ID: 13 Last Platform ID: 13

基于上述情况,尝试强制打开库,报ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1]错误
ora-600 kzbzib_kcrsds_1


对于这个情况,以前有过大量恢复案例,修改数据库scn即可
kcbzib_kcrsds_1报错汇总
12C数据库报ORA-600 kcbzib_kcrsds_1故障处理
存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理
https://www.xifenfei.com/2023/12/patch-scn-ora-600-kcbzib_kcrsds_1.html
此类故障处理太多,不一一列举,解决这个错误之后,数据库open成功,然后安排逻辑迁移即可

第一例Oracle 21c恢复咨询

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:第一例Oracle 21c恢复咨询

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

记录一个Oracle 21c故障的恢复请求(这个是第一个21c的恢复咨询),这个表明21C确实有客户在生产上使用了(不过这个是国外客户,国内的目前还没有遇到)
21c


故障原因是最初的数据文件不一致,数据库无法open,最终经过一系列折腾之后,有数据文件offline的情况下执行了resetlogs,导致部分文件resetlogs scn不一致
wrong-resetlogs

ORA-15411: Failure groups in disk group DATA have different number of disks.

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-15411: Failure groups in disk group DATA have different number of disks.

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户磁盘组以前规划是normal模式,但是由于某种原因,其中一个存储掉线了,出现一下状态

SQL> select group_number,name,path,failgroup,state from v$asm_disk;

GROUP_NUMBER NAME                           PATH                           FAILGROUP                      STATE
------------ ------------------------------ ------------------------------ ------------------------------ --------
           0                                /dev/asmocr1                                                  NORMAL
           0                                /dev/asmocr3                                                  NORMAL
           0                                /dev/asmhdisk15                                               NORMAL
           0                                /dev/asmocr2                                                  NORMAL
           1 DATA_0011                                                     FAL1                           NORMAL
           1 DATA_0010                                                     FAL1                           NORMAL
           1 DATA_0013                                                     FAL1                           NORMAL
           1 DATA_0012                                                     FAL1                           NORMAL
           1 DATA_0009                                                     FAL1                           NORMAL
           1 DATA_0008                                                     FAL1                           NORMAL
           1 DATA_0007                                                     FAL1                           NORMAL
           1 DATA_0006                                                     FAL1                           NORMAL
           1 DATA_0005                                                     FAL1                           NORMAL
           1 DATA_0004                                                     FAL1                           NORMAL
           1 DATA_0003                                                     FAL1                           NORMAL
           1 DATA_0002                                                     FAL1                           NORMAL
           1 DATA_0001                                                     FAL1                           NORMAL
           1 DATA_0000                                                     FAL1                           NORMAL
           1 DATA_0023                      /dev/asmhdisk5                 FAL2                           NORMAL
           1 DATA_0024                      /dev/asmhdisk6                 FAL2                           NORMAL
           1 DATA_0022                      /dev/asmhdisk4                 FAL2                           NORMAL
           1 DATA_0020                      /dev/asmhdisk2                 FAL2                           NORMAL
           1 DATA_0014                      /dev/asmhdisk1                 FAL2                           NORMAL
           1 DATA_0021                      /dev/asmhdisk3                 FAL2                           NORMAL
           1 DATA_0018                      /dev/asmhdisk13                FAL2                           NORMAL
           1 DATA_0019                      /dev/asmhdisk14                FAL2                           NORMAL
           1 DATA_0017                      /dev/asmhdisk12                FAL2                           NORMAL
           1 DATA_0016                      /dev/asmhdisk11                FAL2                           NORMAL
           1 DATA_0027                      /dev/asmhdisk9                 FAL2                           NORMAL
           1 DATA_0015                      /dev/asmhdisk10                FAL2                           NORMAL
           1 DATA_0025                      /dev/asmhdisk7                 FAL2                           NORMAL
           1 DATA_0026                      /dev/asmhdisk8                 FAL2                           NORMAL
           2 OCRVOTE2                       AFD:OCRVOTE2                   OCRVOTE2                       NORMAL
           2 OCRVOTE1                       AFD:OCRVOTE1                   OCRVOTE1                       NORMAL
           2 OCRVOTE3                       AFD:OCRVOTE3                   OCRVOTE3                       NORMAL

35 rows selected.

因为磁盘空闲空间较大

ASMCMD> lsdg
State    Type    Rebal  Sector  Logical_Sector  Block       AU  Total_MB   Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512             512   4096  4194304  29360128  23110032          2097152        10506440             14             N  DATA/
MOUNTED  EXTERN  N         512             512   4096  4194304     92160     91724                0           91724              0             Y  OCRVOTE/

想从data磁盘组中,删除部分盘,释放出来一些空间,结果报ORA-15411: Failure groups in disk group DATA have different number of disks.

SQL> alter diskgroup data drop disk DATA_0027,DATA_0026,DATA_0025,DATA_0024 rebalance power 10;
alter diskgroup data drop disk DATA_0027,DATA_0026,DATA_0025,DATA_0024 rebalance power 10
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15411: Failure groups in disk group DATA have different number of disks.

设置,删除磁盘成功_asm_disable_failgroup_size_checking和_asm_disable_dangerous_failgroup_checking

SQL> alter system set "_asm_disable_failgroup_size_checking"=true scope=memory sid='*';

System altered.

SQL>alter system set "_asm_disable_dangerous_failgroup_checking"=true scope=memory sid='*';

System altered.

SQL> alter diskgroup data drop disk DATA_0027,DATA_0026,DATA_0025,DATA_0024 rebalance power 10;

Diskgroup altered.