每个迁移方案都有优缺点，只是适用的场景不同而已。针对特别大的表空间，由于环境限制，使用数据泵进行迁移，注意操作点，也可以完成。对比TTS，数据泵迁移完成后，还会有效的降低空间使用率，整理表碎片。

接上次30w+对象的表空间迁移完成后，又有一个迁移表空间的需求，但是不同的是，这个表空间包含的对象很少，那么我们又是用什么方法迁移哪？再迁移的过程中有什么坑哪？为了以后更好的实施迁移，有什么最佳实践可以参考的哪？本文将详细进行说明，敬请期待。

单个表空间10T大小，30w+个数据对象，当客户提出需求，需要进行历史数据归档，迁移至其他历史库，面对实际复杂的环境要求和各种各样的迁移工具，我们应该选择一种适合本场景的迁移方案。

本次测试DFT的方式进行XTTS迁移，他与RMAN之间的区别就是，在初始化备份的时候，DFT可以不落地，直接通过网络从源端存储到目标端数据目录中，适用于本地没有多余可用空间的场景。

XTTS--利用XTTS迁移单个表空间环境准备在实际工作中，可能有种需求，库里面的某个表空间存的全部是历史数据，由于某种原因（历史数据归档，迁移至历史库或者由于正式库存储压力，迁移到别的空间充足的库归

在实际工作中，可能有种需求，库里面的某个表空间存的全部是历史数据，由于某种原因（历史数据归档，迁移至历史库或者由于正式库存储压力，迁移到别的空间充足的库归档），需要把某个具体的表空间迁移到另一套库中。你能想到什么办法哪？

linux 操作系统，crontab 是一个常见的任务调度工具，用以我们日常的定时任务。但是有时crontab 并不会正常执行，会有一些奇奇怪怪的情况发生，万源归宗，只要有日志，任何错误均能被发现

一个简单的数据泵逻辑迁移，没想到出现了这么多问题，如遇知晓，请继续往下读 # 需求 现在有一套环境，2节点rac 11.2.0.4.0，os版本：Red Hat Enterprise Linux S

supplemental logging，顾名思义，就是附加日志，额外会在redo中添加的日志，因为普通的update记录，只会记录更新值得字段变化和rowid，但是在不同库之间，rowid就不能用了，只凭一个更新字段，无法确定唯一的一行。所以以上测试的重点，就是在不同的情况下，redo中到底还会额外存储哪些日志。通过lognminer，可以清晰的看到，不同的场景，redo里面会额外存储的列也不同，因为触发的条件不同。

当有表的字段发生ddl改变后（drop clomun，add column，drop table），推荐使用DICT_FROM_REDO_LOGS。

logminer实战：查找删除数据的元凶

继上一篇介绍了logmnr的基本概念，验证了使用数据字典存储在redo日志中的方法来挖掘，然后还有一种使用在线目录的方法进行挖掘，下面就对这种方法进行介绍，并最后做一个总结。

@[TOC](基本概念与操作) 当用户误操作了需要恢复时，或者需要进行审计用户操作，或者当为了探寻数据库内部原理时，logmnr就是一个非常好用的利器。

@接上篇本地索引的测试。对于分区索引，需要区分创建的是全局索引，或本地索引：全局索引(globalindex)：即可以分区，也可以不分区。即可以建range分区，也可以建hash分区，即可建于分区表，

在平常的工作中，我们可能由于业务原因，对分区表进行维护。网上有很多说法，什么操作导致哪种索引会失效，但都是人云亦云，下面通过具体测试打出结论。

在不同的数据库版本，恢复oracle adg gap的步骤也不一样，随着版本的升级，命令极大的简化，从18c之后，一条命令就可以恢复GAP。但是其中的原理却大有千秋。

当我们ASM磁盘空间不够时，一般我们都会选择扩容，往磁盘组中添加新的磁盘，然后等待完成rebalance即可。但是，当我们没有注意到一些情况时，可能就会扩容失败。下面就说一种可能之前没有注意到的地方，导致扩容失败的场景。

@关于MySQL的droptable可能有很多恢复的方法，下面说一种，基于全备，复制，然后让sqlthread停在一个指定位置的方法来恢复。下面进行模拟恢复环境信息MySQL版本信息：Serverve

@[TOC](MySQL 8.0二进制安装 ) # 下载MySQL二进制包 官网地址，下载MySQL：[https://dev.mysql.com/](https://dev.mysql.com/)

oracle adg出现长时间gap，基于普通的增量备份恢复可以解决一些问题，但也不是万能的，又是还需要一些特别操作。

@oracleasm磁盘在实际工作中，由于一些原因，可能会不可访问，有时造成磁盘组直接dismount，数据库重启，有时磁盘组状态没影响，还是mount。那么到底磁盘出现什么状况？会造成磁盘组dism

@directtrue的官方解释接上篇文章。最后提升加载速度的内容，其中有一项，是使用直接路径加载：directtrue。直接加载全部记录，提高速度。但是此方法有个副作用，就是会使索引失效。mos上面

asm扩容本来是件很简单的事，当asm磁盘准备好之后，直接一条命令就会添加上。但是也会有异常情况，最近就碰到19c在扩容的时候，报错的故障，供大家参考。集群处于ROLLINGPATCH模式

NetworkManager开着吧

@[TOC](os header block结构中file_size的大小计算)# 概述 看了roger大师写的恢复redo os header block的文章，链接：[详述Redo日志中操

@[TOC](2021年4月Oracle数据库补丁分析报告)# 引言## Oracle中大批量删除数据的一种方法http://blog.itpub.net/26390465/viewspace

这个里面配置的归档日志删除策略一般是对归档路径在FRA中的生效。

oracle最新安全补丁已经发布，可能有很多人还没有安装最新版补丁，此文档分析了安装安全补丁的必要性，更是提供了完整的安装和报错处理步骤。

拿错误的scn搜索，就能搜索到，84e586bf，应该是块上面的scn不一致导致的

1、oracle可执行文件权限是否正确；2、asm磁盘组状态是否正常3、oracle数组是否正确。参考mos:2545858.14、是否有rebalance未完成。

srvctl modify asm -count ALL

参考下这篇mos，算是一个bug吧：INS-06006 GI RunInstaller Fails If OpenSSH Is Upgraded to 8.x (Doc ID 2555697.1)

bootstrap$所包含的对象，针对object_id大于56的非核心对象，可以通过event 38003 来进行屏蔽，然而，对于object_id 小于56的核心对象来讲，38003 event是无效的，只能通过bbed等极端手段来进行处理。

可以修改一些参数，如：alter session set workarea_size_policy=MANUAL;alter session set db_file_multiblock_read_count=512;alter session set events ‘10351 trace name context forever, level 128’;alter session set so