olap数据库 prestoclickhousehivegppg

转载

mob64ca140b466e 2024-10-19 09:52:54

文章标签 数据库 oracle sql 数据 文章分类 Hive 大数据

数据库管理 2022-11-04

第四十二期复盘一下

1 跨版本PDB迁移后续操作
2 Bug 32128969
3 DELETE & TRUNCATE
4 喜闻乐见
总结

第四十二期复盘一下

上周几乎割接了一周，一次IPv6环境改造配合，X8M的IPv6改造一次，X9M改造一次，X86 RAC改造一次、回退一次，3个生产系统PDB迁移，X8改造一次，当然其中有些是parallel的。
最大的感受就是熬夜伤身，本周一凌晨完成割接过后，到现在都还没有恢复，这其中包含了如何调整被破坏的生物钟，还有就是熬夜本身带来的休息不足。
技术向，知道写了些啥。

1 跨版本PDB迁移后续操作

本次3个系统的跨版本PDB迁移，相较于二十三期的内容（因为不小心覆盖了，详见25期最后文档分享），多了一些内容。因为当前环境中数据库组件是添加的APEX的（其实也没人用），在原本升级操作后该组件状态虽然是VALID，但是要完成完整操作并和数据库组件版本一致还是要对APEX进行升级。
在之前的测试过程中，各种关于APEX的官方文档都详细讲述了APEX组件的安装过程，然而在PDB包含过去版本组件时，执行安装的时候会出现错误。而对APEX组件如何卸载这件事，却没有讲解。通过大量查阅资料并进行测试，汇总了相关操作：

alter pluggable database xxxx open upgrade;

dbupgrade -c 'XXXX'
cd $ORACLE_HOME/apex

alter pluggable database xxxx open upgrade;
alter session set container=xxxx;
alter session set "_oracle_script"=true;
drop user APEX_050000 cascade; --针对12.2对应APEX组件版本，其他版本根据情况调整
drop user APEX_PUBLIC_USER cascade;
drop package SYS.WWV_DBMS_SQL;
@apexins.sql SYSAUX SYSAUX TEMP /i/
exit --建议重新进入sqlplus

alter session set container=xxxx;
@?/rdbms/admin/utlrp.sql --then restart the pdb

2 Bug 32128969

X8那台机器运行的GI和DB版本是19.6，正正好好装在Bug 32128969的枪口上，在阅读Bug包里的README文档时发现了以下内容：

olap数据库 prestoclickhousehivegppg_oracle

olap数据库 prestoclickhousehivegppg_sql_02

然而在对应目录下并没有emocmrsp这个命令，通过在MOS上搜索发现 OPatch: Behavior Changes starting in OPatch 12.2.0.1.5 and 11.2.0.3.14 releases (Doc ID 2161861.1)：

olap数据库 prestoclickhousehivegppg_sql_03

大意就是现今版本的OPatch不再包含emocmrsp命令，在应用相关补丁的时候也不需要执行-ocmrf参数（这是OPatch更加智能的表现=_=!）。因此，在应用Bug 32128969补丁时，直接opatchauto apply即可。

回头看看Bug 32128969的README，就会发现，其实这个文档应该是基于以前其他Bug或者模板进行修改的，里面的“bug”其实不止OPatch这一项（=_=!!）

3 DELETE & TRUNCATE

这两个东西，主要是昨天听说群内同行大佬一天遭受两次打击：没带条件的delete删了全表（一小时后才报）；truncate一张生产表。环境是PostgreSQL，如何解决的大佬还没有分享，坐等大佬分享。
当然我在Oracle环境也遇到过相关的问题。首先delete和truncate都是删除数据的操作，但是二者还是有区别的：首先，delete是DML语句，会触发事务，产生redo和undo，需要通过commit来提交完成事务或者rollback来回滚事务；truncate是DDL语句，不触发事务，直接对对应数据进行物理毁灭。
从二者区别来看，delete误操作是要比truncate简单一些的，如果事务没有完成，可以通过rollback来避免事务完成。但如果commit了，在达到数据库undo retention配置值之前且undo表空间还有足够空间即对应的undo数据还在，也可以通过undo来恢复数据：

create table xxx_new as select * from xxx as of scn/timestamp ...;

但如果undo信息已经丢失，这种方法是无效的，这种情况就和truncate比较类似了，如果有rman备份，可以通过备份进行异机非完全恢复来实现丢失数据的恢复（有dump备份也行，但肯定会丢失一部分数据）。但如果没有多余的机器用于备份恢复怎么办？Oracle在12.2也引入了一个新的恢复方式：

rman target /
run {
recover table schema.table_name of pluggable database pdb_name
until time '2020-11-29 12:00:00'
auxiliary destination  '/u01/app/oracle/recover'
datapump destination '/u01/app/oracle/recover/dumpfile'
dump file 'schema_table_bak.dmp'
notableimport;
}

rman会启动一个辅助实例来恢复且仅恢复对应的表信息，完成dmp文件生成后，导入数据库即可。
要是没rman备份也没dump备份，那就自求多福吧。