海量数据迁移之通过shell估算数据量

在数据迁移的时候,需要根据用户量来评估需要在表空间理添加的空间大小。比如迁移5百万的用户和迁移200万,两者需要添加的数据量差别很大,在资源有限的情况下,需要一些比较合理的估算,毕竟在生产环境中做数据加载的时候报了空间不足的问题就是准备太不充分了,稍后的数据修复任务就难上加难。
比如我们现在客户提供了如下的信息,需要我们评估一下在目前的用户基础上迁移几百万用户需要添加的空间。
表空间假设是如下的存储情况。DATA开头的表空间存放表数据,INDX开头的表空间存放索引数据。

Tablespace Init extent Total MB Free MB Used MB
-------------------- ---- ------------ ---------- -----------
DATAH01 16M 572,113 135,408 436,705
DATAL01 8M 216,179 141,360 74,819
DATAM01 4M 291,840 85,280 206,560
DATAS01 1M 302,080 74,508 227,572
INDXH01 4M 174,033 96,256 77,777
INDXM01 2M 141,312 56,812 84,500
INDXS01 128K 240,640 72,241 168,399
sum   1,938,197 661,865 1,276,332

现在得到的是整个数据库的存储情况。用户说现在库里还有600G左右的空间,让我们评估一下再迁移几百万的用户的情况需要多少空间。
比如数据库里用到的表有1000张,可能做数据迁移的时候关联的表只有100张。那么我们不能按照如下的比例来做计算。
10%*total_size*新添加的用户占用的比率

这样肯定是不科学的,而且估算的空间肯定是偏小的。
比如memo这一个表就80多个G,按照百分比计算就会出问题。

TABLE_NAME                        SIZE_MB TABLESPACE_NAME
------------------------------ ---------- ------------------------------
MEMO                            81613 DATAS01

而从客户的角度出发,他们需要的结果类似下面的表格内容。
如果提供了如下的表格,客户一看就一目了然,大概需要添加多少的空间。

INDEX_SIZE TOTAL_SIZE INDXH01 INDXM01 INDXS01  
sum 306093 62836 57302 185392  
           
           
TABLE_SIZE TOTAL_SIZE DATAH01 DATAL01 DATAM01 DATAS01
sum 546981 132944 72400 126508 215129

我采用了如下的两个shell脚本来做计算。
如下的脚本计算存放表数据的表空间的数据量
我们假设我们有一个文件,里面是数据迁移中用到的表清单,取名为tablst,然后通过如下的脚本来做计算。

awk '{print "'\''" $1 "'\''" ","}' tablst |sed -e '/^$/d' -e '$s/.$//' > tablst.temp
table_list=`cat tablst.temp`

sqlplus -s  xxxxxxx
set linesize 200
set pages 100
col table_name format a30
break on report
compute sum of total_size on report
compute sum of INDXH01 on report
compute sum of INDXM01 on report
compute sum of INDXS01 on report

 select table_name,
      sum(size_MB) total_size,
      sum(decode(tablespace_name,'INDXH01', size_MB,0)) INDXH01,
      sum(decode(tablespace_name,'INDXM01', size_MB,0)) INDXM01,
      sum(decode(tablespace_name,'INDXS01', size_MB,0)) INDXS01
     from (select idx.table_name, round(sum(seg.bytes/1024/1024)) size_MB,seg.tablespace_name from  user_segments seg,user_indexes idx where seg.segment_name=idx.index_name and  idx.table_name='MO1_MEMO' group by idx.table_name,seg.tablespace_name)
    group by table_name;

EOF
rm tablst.temp

假设我们我们计算3个表。MEMO,CHARGE,CHARGE_REL,运行脚本后我们得到如下的清单,就很清楚的看到,哪些表占用了多少空间,在哪个表空间。
TABLE_NAME                     TOTAL_SIZE    DATAH01    DATAL01    DATAM01    DATAS01
------------------------------ ---------- ---------- ---------- ---------- ----------
    CHARGE                         104720     104720          0          0          0
    MEMO                            81613          0          0          0      81613
CHARGE_REL                          12672      12672          0          0          0
                               ---------- ---------- ---------- ---------- ----------
sum                                199005     117392          0          0      81613

通过如下的脚本来估算索引的表空间使用情况。

awk '{print "'\''" $1 "'\''" ","}' tablst |sed -e '/^$/d' -e '$s/.$//' > tablst.temp
table_list=`cat tablst.temp`

sqlplus -s  xxxx
set linesize 200
set pages 100
col table_name format a30
break on report
compute sum of total_size on report
compute sum of DATAH01 on report
compute sum of DATAH01 on report
compute sum of DATAL01 on report
compute sum of DATAM01 on report
compute sum of DATAS01 on report
 select table_name,
      sum(size_MB) total_size,
      sum(decode(tablespace_name,'DATAH01', size_MB,0)) DATAH01,
      sum(decode(tablespace_name,'DATAL01', size_MB,0)) DATAL01,
      sum(decode(tablespace_name,'DATAM01', size_MB,0)) DATAM01,
      sum(decode(tablespace_name,'DATAS01', size_MB,0)) DATAS01
     from (select segment_name table_name, round(sum(bytes/1024/1024)) size_MB,tablespace_name from  user_segments where segment_name in ($table_list) group by segment_name,tablespace_name)
    group by table_name;

EOF
rm tablst.temp

运行后得到的如下的一个清单,就可以看到表对应索引的存储情况。
TABLE_NAME                     TOTAL_SIZE    INDXH01    INDXM01    INDXS01
------------------------------ ---------- ---------- ---------- ----------
    CHARGE                          27004      21620          0       5384
       CHARGE_REL                  28868      28868          0          0
    MEMO                            33999          0          0      33710
                               ---------- ---------- ---------- ----------
sum                                 89871      50488          0      39094

得到了如上的列表,需要评估数据量的情况就有思路了。
可以基于当前数据库中的剩余空间来排查目前的空间是否足够,如果不够需要添加多少。

Tablespace Init extent Total MB Free MB Used MB
-------------------- ---- ------------ ---------- -----------
DATAH01 16M 572,113 135,408 436,705
DATAL01 8M 216,179 141,360 74,819
DATAM01 4M 291,840 85,280 206,560
DATAS01 1M 302,080 74,508 227,572
INDXH01 4M 174,033 96,256 77,777
INDXM01 2M 141,312 56,812 84,500
INDXS01 128K 240,640 72,241 168,399
sum   1,938,197 661,865 1,276,332

得到一个基本的清单,我们就需要加入一定的buffer空间,个人觉得控制在30%左右比较好。这样留有一定富余。
最后给客户的建议就是如下的清单,客户一看就一目了然。

INDXM01 +50G

INDXS01 +100G

DATAM01 +50G

DATAS01 +100G

    

时间: 2024-07-30 10:57:08

海量数据迁移之通过shell估算数据量的相关文章

海量数据迁移之使用shell启用多个动态并行

在数据迁移中,可能有成百上千个表,有些表很大,有些表又很小. 如果启用了多个并行的进程,可能会有资源分配上的问题. 比如下面有10个表,100代表预计的时间为100分钟. table1  100 table2  90 table3  90 table4  80 table5  80 table6  70 table7  60 table8  60 table9  50 table10 40 如果分为4个进程来并行执行,可能一种比较理想的方案就是 parallel1: table1,table8

关于大数据量下Core Data的数据迁移

Core Data版本迁移基础 通常,在使用Core Data的iOS App上,不同版本上的数据模型变更引发的数据迁移都是由Core Data来负责完成的.这种数据迁移模式称为Lightweight Migration(可能对于开发人员来说是lightweight),开发人员只要在添加Persistent Store时设置好对应选项,其它的就交付给Core Data来做了: 从命名上可以看出这两个选项分别代表:自动迁移Persistent Store,以及自动创建Mapping Model.

阿里云提供服务器免费数据迁移 数据量高达1T

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 近日,阿里云推出了一项免费数据迁移服务,在8 月1 日到9 月30日期间,一次性购买阿里云服务器时长超过6 个月的用户均可免费享受数据迁移服务.近期,阿里云发布"站上云端"计划,以帮助中小网站迁移到云服务器上,并紧接着推出了云服务器的团购活动,以促进用户的购买.此次免费数据迁移服务是为了进一步降低用户迁移到云服务器的成本,

阿里云发布移动数据中心“闪电立方”:为PB级海量数据迁移而生 

在人人习惯网络下载的时代,像快递一样来搬数据显得有点奇怪?其实这才是企业需要的.  6月10日,在2017年云栖大会·上海峰会上,阿里云发布了一款重磅级产品--"闪电立方".它像是一个可移动的"数据中心",通过一个安全的存储硬件,可将100TB数据安全地一次性转移,最快24小时即可完成PB级数据迁移. 尽管当前网络带宽不断增长,但相对于数据量的增长而言好像还不够,尤其是当数百TB以上数据要在不同的服务器中转移时.物理迁移则是被业内公认的最佳数据迁移方案,<计算

数据仓库 hadoop-数据仓库基础数据量大,ETL处理速度慢,查询慢,hadoop能否解决问题?如何迁移到hadoop?

问题描述 数据仓库基础数据量大,ETL处理速度慢,查询慢,hadoop能否解决问题?如何迁移到hadoop? 1.基础数据主表2亿以上数据 2.基础层到中间层的汇总处理(每天处理),ETL处理比较花时间 某些任务一个小时左右才能处理完 3.SQL已经无法再优化 4.这种情况想到hadoop,不知hadoop是否能解决,如何解决? 5.我以下思路是否可行: 基础数据导入hadoop, ETL处理过程由hadoop处理,处理结果再导回数据库 6.问题hadoop中如何进行多表关联查询或者类似存储过程

阿里云提供服务器免费数据迁移数据量高达1T

近日,阿里云推出了一项免费数据迁移服务,在 8 月 1 日到 9 月 30 日期间,一次性购买阿里云服务器时长超过 6 个月的用户均可免费享受数据迁移服务.近期,阿里云发布"站上云端"计划,以帮助中小网站迁移到云服务器上,并紧接着推出了云服务器的团购活动,以促进用户的购买.此次免费数据迁移服务是为了进一步降低用户迁移到云服务器的成本,解决用户在购买阿里云云服务器后,需要迁移原服务器中数据和需要重新安装软件的烦恼,阿里云将为符合条件的用户提供免费的数据迁移和软件安装服务,把数据库数据.附

Mysql大数据量存储及访问的设计讨论

一.引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极大的问题.通过数据切分来提高网站性能,横向扩展数据层已经成为架构研发人员首选的方式.水平切分数据库,可以降低单台机器的负载,同时最大限度的降低了了宕机造成的损失.通过负载均衡策略,有效的降低了单台机器的访问负载,降低了宕机的可能性:通过集群方案,解决了数据库宕机带来的单点数据库不能访问的问题:通过读写分离策略更

海量数据迁移之外部表并行抽取

在10g开始的新特性中,外部表是一个不容忽视的好工具.对于大型项目中海量数据使用sqlloader是一种全新的方式,不过很明显,sqlloader的可扩展性更强,但是基于oracle平台的数据迁移来说,外部表的性能也不错.对于数据迁移来说也是一个很好的方案. 使用外部表来做数据迁移,可以"动态"加载数据,能够很方便的从数据库中加载数据,对于数据校验来说就显得很有优势了,而对于sqlloader来说,可能得等到数据加载的时候才知道是不是有问题,如果对于数据的准确性要求极高,可以使用外部表

数据量过大时数据库操作的处理

数据|数据库 随着"金盾工程"建设的逐步深入和公安信息化的高速发展,公安计算机应用系统被广泛应用在各警种.各部门.与此同时,应用系统体系的核心.系统数据的存放地――数据库也随着实际应用而急剧膨胀,一些大规模的系统,如人口系统的数据甚至超过了1000万条,可谓海量.那么,如何实现快速地从这些超大容量的数据库中提取数据(查询).分析.统计以及提取数据后进行数据分页已成为各地系统管理员和数据库管理员亟待解决的难题. 在以下的文章中,我将以"办公自动化"系统为例,探讨如何在