和开发讨论的一个数据变更需求(r9笔记第8天)

最近在评估一个开发同事的需求时，发现随着需求的变化，DBA相关的评估工作也会随之变化，同时反射到开发同事那边，通过这个案例也可以看到很多的需求变化，可以从中看出很多的不足和改进之处。 首先开发提出的一个数据需求，删除数据库中的几张表数据，然后把剩下的数据都备份，把备份集拷贝到一个异机环境。其实这个需求在之前也很他们沟通过，这是他们业务迁移的一个步骤，同时做一些业务梳理，DB这边需要配合做一些数据的清理的工作。 这种工作其实对我来说是一件好事，如果有一天我发现我在维护一个T级的数据库，但是数据库里的数据从来用不到，垃圾成山，我会有一种很深的负罪感，至于为什么这么说，我后面再解释。 我们在很早之前沟通的结论，开发同事提供一个列表清单，删除这些清单中的表数据，这样能够完成一些业务的梳理和数据清理，然后提供一个初始的备份交给他 们，后期如果需要做一些特殊的数据恢复有据可依，然后在这个基础上他们会把另外几个业务线的数据迁移过来，提供资源的利用率。 所以看到这个需求之后就好像我们之前的暗号一样，我开始按照计划来做一个详细的评估，但是评估发现原来的方案有一些硬伤。 当前所在的环境是一主一备，数据量在1.7T左右。磁盘空间的利用率达到了95%以上，意味着系统中已经没有多少的剩余空间。根据我查看 dba_segements的分析，发现需要删除的数据大概在300G左右，这对于1.7T的数据量来说不是多大的提升，所以我的初步评估就是做数据备份 还是有难度的，一来备份集太大，恢复起来难度很大，二来本地磁盘空间不足，想导出数据绝非易事。 当然我提出难处，还得有解，我的一个建议就是直接把备库的数据文件都拷贝过去，顺带控制文件，参数文件，这样两个难点看起来都能够解决，一来恢复起来非常 容易，只需要启用数据库即可，二来磁盘空间不足的问题可以缓解，可以直接通过rsync或者ftp，scp的方式传输过去。这种方案对于开发同事来说，虽 然听起来要复杂一些，但是他们实际想来发现也是受益的，所以也能够理解我的想法。他们评估了一下，认为还是可行的。 但是这个时候我突然想到了一个问题，那就是主备库的磁盘空间问题，如果我要导出备份，1.7T的数据，如果直接拷贝数据文件，得花费半天左右，而在这半天 的时间里，如果产生大量的归档，在备库无法应用就会一直挤压下来，到时候还是会撑爆磁盘空间，主备库都有一定的风险，我在使用脚本查看了主库的归档频率情 况之后，更加坚定了我的担心，主库每天的归档在早上大概会有60g左右，也就意味着在半天的时间范围内，主库的空间很可能被撑爆。而备库是计划是停库直接 拷贝数据文件，这个时间持续太长，潜在风险还不少。所以虽然我建议了传输数据文件，突然发现有些事情结合具体环境来看还是有一定的风险，需要综合评估来 看。 当然我不能一会一个主意，这也会给开发的同事造成很多不专业的影响，所以我简单的描述了现在的情况，决定还是在数据清理之后再来看看实际的数据使用率再来 决定。删除的工作也是反复确认，最后直接动用了truncate,删除数据冗余，创建数据艰难，删除的工作总共持续了不到一分钟，查看磁盘空间使用情况， 让我大吃一惊，空间剩余1.5T左右，也就意味着删除了近1T多的数据。 这些数据都是和开发同学反复确认之后操作的，所以在这一点上我也就心安理得了。空间清理的幅度如此之大，让我有些招架不住，如此一来，还拷贝数据文件干什 么，直接导出数据，大概会在100G左右，直接推送到目标端，也真心不是什么难事。所以这样一来留给开发的任务看起来就更加明朗了，我可以主动推送文件给 他们或者他们来抓取。 而我在这个基础上还有一些工作要做，其中重要的一环就是收缩数据库空间，这个操作可以使用resize datafile的方式来实现，可以使用如下的SQL语句来实现。 select a.file#,a.name,a.bytes/1024/1024 CurrentMB, ceil(HWM * a.block_size)/1024/1024 ResizeTo, (a.bytes - HWM * a.block_size)/1024/1024 ReleaseMB, 'alter database datafile '''||a.name||''' resize '|| ceil(HWM * a.block_size/1024/1024) || 'M;' ResizeCMD from v$datafile a, (select file_id,max(block_id+blocks-1) HWM from dba_extents group by file_id) b where a.file# = b.file_id(+) and (a.bytes - HWM *block_size)>0 我可以根据删除的收益（能够释放的空间情况）来决定是否需要运行相应的SQL语句，一番折腾之后，物理磁盘空间马上又释放了几百G。 在这个基础上，其实我们还是可以进一步分析数据文件的高水位线，1T多的数据文件，实际的数据使用率才200G左右，肯定有些数据库对象占用了高水线的位 置，导致很多数据文件无法收缩。当然这个工作也是个细活，需要分析dba_extents，结合dba_segements，目前还没有想好怎么自动化分 析这个问题，最近有时间了可以搞搞，目前还是手工来做的。