单表40亿条记录的表分区 40qzxyd]

发布时间:2017-1-25 3:17:34 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"单表40亿条记录的表分区 40qzxyd]",主要涉及到单表40亿条记录的表分区 40qzxyd]方面的内容,对于单表40亿条记录的表分区 40qzxyd]感兴趣的同学可以参考一下。

用的是SQL SERVER2008,其中有一表数据达40亿条记录,由于此数据库是24小时实时运行,要求对数据库不停机、不影响系统正常运行的情况下进行表分区,请问各位怎么实现? 记得ALTER INDEX时有online=on的设置,表分区却没有这样的参数了。

引用楼主 qzxyd 的回复:数据库不停机、不影响系统正常运行的情况下纯帮顶。

要求对数据库不停机、不影响系统正常运行的情况下进行表分区,请问各位怎么实现? 这样能实现吗?不是会卡死掉么?

http://www.builder.com.cn/2008/0807/1046538.shtml

引用 2 楼 wyy12802 的回复:要求对数据库不停机、不影响系统正常运行的情况下进行表分区,请问各位怎么实现? 这样能实现吗?不是会卡死掉么? 我也顶

先做备份,这种情况只有尝试了,这么大的数据量,操作起来,结果到底如何,说不准哦

 我的方案如下: create partition function pf .... create partition scheme ps ... create CLUSTERED index .......with(online=on) on ps(...) 正在运行,业务也正常运行。不过我的4核4cpu服务器没到100%

引用 6 楼 qzxyd 的回复: 我的方案如下: create partition function pf .... create partition scheme ps ... create CLUSTERED index .......with(online=on) on ps(...) 正在运行,业务也正常运行。不过我的4核4cpu服务器没到100% 但愿没问题....

40亿  移动的数据

第一次见报这么大的数据  , 帮你顶.

到了亿的级别的数据库 太牛了 再怎么没影响总也有影响的.就连电信 银行数据维护切割都有时候要发通知的 帮顶帮顶

运行两三天了,还没结束,速度太慢,不知还有么有更快的方法,不影响系统运行。

你胆子真大,在产品环境上做这么大改动。。。。。 建议新建一张分区表,在产品环境比较闲暇的时候将数据倒到新表中;最后用新表替换旧表。 这样做的好处是第一很安全,第二,速度肯定比你直接强加分区块,因为你在新表上可以先没有索引,数据全进去后再加上。缺点就是需要有空闲的空间。 一般这么大的产品库,绝对不推荐线上直接修改。成功了是侥幸,出问题是常态,出了问题你就要兜着走

最好还是有备份服务器的,这样做分区和索引时必须的,亿级别的数据量。

引用 12 楼 kinsa 的回复:你胆子真大,在产品环境上做这么大改动。。。。。 建议新建一张分区表,在产品环境比较闲暇的时候将数据倒到新表中;最后用新表替换旧表。 这样做的好处是第一很安全,第二,速度肯定比你直接强加分区块,因为你在新表上可以先没有索引,数据全进去后再加上。缺点就是需要有空闲的空间。 一般这么大的产品库,绝对不推荐线上直接修改。成功了是侥幸,出问题是常态,出了问题你就要兜着走 这里可能有几个问题: 1.”将数据倒到新表中“,这个倒到是怎么操作了,INSERT、还是数据库表的导入,这都是一个长时间的操作呀 2.”最后用新表替换旧表“,新表不停在增加数据,当分区操作搞完需要一两天,这时已经不少数据了,又要把新数据INSERT进新表,也是一个不小的操作的。 不知这两你怎么考虑?

40亿?除了羡慕别无他语。

我 300万都处理不好,40亿 ,恐怖啊

40亿的数据? 我想知道,占用了多少存储空间?数据增长如何? 系统有什么冗余措施? 现有的分区方案是什么?

该回复于2010-09-29 13:09:01被版主删除

40亿 机器肯定动补了

40乙, 數據量太龐大了。。。最好是用服務器集群服務, 使用多個服務器 分區。 還有電信、銀行的數據,很多都是存在硬件設備的緩存裡,設備投資非常大的。 如果單服務器,你用銀河一號差不多。。。。。

40亿?除了羡慕别无他语。

1:先创建一张新表,将在线数据最新插入的数据入到新表中 2:创建规划一分区表,将原来40亿数据量的表交换分区到分区表中 3:将在心数据直接插入分区表中 4:将新建表插入分区表中

试试 分批将数据导入到新表 当然新表上分区吧

引用 22 楼 xlfd2005 的回复:1:先创建一张新表,将在线数据最新插入的数据入到新表中 2:创建规划一分区表,将原来40亿数据量的表交换分区到分区表中 3:将在心数据直接插入分区表中 4:将新建表插入分区表中 谢谢,我现在做的与你这个思路相似,但有不同 1.将现有表更名如told(40多亿数据) 2.建立一张一模一样的新表,名字为前表名,并建立分区方案,在线数据使用此表 3.将tOld通过BCP命令导入新表 注:1、2时间很短,停机一分钟就搞定,3需要时间很长,但都是一些老数据,使用频度不高,也不会太大影响使用 这个思路还是有一些缺陷,不能做到完全不停机、不影响应用,只能把影响减小,如果各位还有好的思路希望探讨

数据还不是一般的多

40亿   牛啊   最好做个备份 先自己玩玩试试  确定没问题  再操作不迟啊!!!

顶下!

羡慕啊

真的太高兴了

搞定了? 热点数据是如何处理的?

SQL Server 2000 sp4 绿色便携企业版20101012更新下载 具有99.9%功能的企业版SQL SERVER 2000 体积超小(安装包仅30MB),安装简单,便于携带,并且可适用于XP操作系统。可以通过外网IP连接,可以自动定时备份,企业管理器、查询分析器、事件探查器……等一应俱全。 绝对值得您拥有。适用于程序开发者、软件应用者、单机、多机服务器。 联系:QQ 1·7·4·6·6·6·2·0·0   分卷压缩: 1、http://download.csdn.net/source/2747664 2、http://download.csdn.net/source/2747689 3、http://download.csdn.net/source/2747728 注册表补丁:http://download.csdn.net/source/2750545 mysql 4.0.27 绿色免安装经典稳定版下载 http://download.csdn.net/source/711792 mysql-5.1.28-rc完美绿色免安装版下载 http://download.csdn.net/source/711771

楼主的问题,很值得我们去学习、探讨 ~~~~~ (^_^)

引用 15 楼 dawugui 的回复:40亿?除了羡慕别无他语。 这样的问题就不要在这里支付技术分解决了,支付人民币解决吧

一张表40亿,这辈子还没有碰到过。

................

40亿基本不会做对象关系处理的,用对象型数据库意义不大,可以考虑no-sql数据库,比如mongodb

mongodb不但可以做分布式存储,且支持主备模式,还可以同时解决备份,故障转移问题.

40亿不停的插入,删除会占用大量空间的,建议不停的进行数据收缩处理,不然有可能最后数据库绷溃

40亿不停的插入,删除会占用大量空间的,建议不停的进行数据收缩处理,不然有可能最后数据库绷溃

40亿不停的插入,删除会占用大量空间的,建议不停的进行数据收缩处理,不然有可能最后数据库绷溃

建议先备份数据库,这是最重要的!

这么大的数据量  羡慕中

有几点疑问 1. 为什么单表数据这么大?是否有必要?是否有过历史数据归档? 2. 40亿的数据平时业务必须用到的有多少? 3. 这张表的一些基本信息及环境配置是什么?表记录数有了, 列数量,表存储,约束,索引等等。 服务器的内存,CPU,存储IO等等。 如果考虑HA,建议尽早实施HA方案。如Database mirroring, Cluster等,有了HA,处理起来就方便多了,否则以后类似的需求,头依旧会大...

该回复于2011-02-16 09:00:29被版主删除

40亿的数据量,这什么多

该回复于2011-03-10 10:03:38被版主删除

....40亿哦 + 帖子的时间 ===神贴

没有必要将这么多的数据放在一个单表里面吧

我手里也有一个3.5亿的表

偶最多对2000W记录的表进行处理 但是也是会经常对已无用数据进行倒表处理

最多也就对6000多万的数据进行处理,还是td

我们的单表数据有70G 呵呵

这么大的数据量,CPU能拉得动么

CSDN没人发问了吗? http://bbs.51cto.com/thread-794007-1.html

关注学习借鉴贴!

这个数据量就不仅仅是单纯的技术问题了 要权限业务运作的问题,比如哪些数据是可临时停多长时间,要权衡分步处理了

是否可以尝试触发器 1、先建新的分区表,同时在旧表上建触发器insert到新表中 2、根据表中的时间列比较旧表的与新表的差异,通过分区列将旧表的数据分批导入新表。 上述两步均不影响生产。 3、切换新表为生产环境。先将旧表set read_only,然后让程序员修改程序将表名替换为新表并上传就可以了。 切换时间看程序的启动时间,在cache失效前,不影响读访问。

40亿数据,感觉除了日志数据还是日志数据。这样的存储方式做线上操作太难了~!

mark一下,纯顶 羡慕。。学习中

找微软支持吧

40亿?除了羡慕别无他语。

我以前做的一个系统,数据量最多到了12亿,慢点都快崩溃了,实在没办法了就一点点的往别的表转移数据才解决的问题。 其实出现这问题主要是事前没规划好,应该做一个表容量的检查,例如数据到了1千万就转移到别的表,就不会出现这问题了。

羡慕 。。这样操作风险很大啊 

40亿数据多少G的表? 建一个新表 有分区的 然后同库订阅到新表 然后改表名 不过还好要停一下下

关注中

对表进行Archive操作应该可以很好的解决你的问题。 1.创建按时间的Archive表(比如按时间段分区,每年?每季度?每月?这个有你来决定) 2.建立视图:视图是对所有Archive表和当前表的UNION ALL操作(为了防止对APP的影响,建议将视图名和表名称保持一致) 3.建立Archive操作的Procedure 4.建立Archive操作的Job,调用3中的Procedure 1.create table tb_01/tb_02...tb_12 2.exec sp_rename 'Current_table','tb_current_table' 3.create view Current_table AS  select * from tb_01  UNION ALL  select * from tb_02 ... UNION ALL select * from tb_current_table 这里第2和第3步一起执行,客户端应该只有很短时间的影响(如果没有客户连接过来就没有影响) 4.create proc up_Archive_data... 5.create job

帮顶 学习学习

40亿 听着都头疼, 肯定需要停止一会写操作的

我赛,牛呀!

40亿的数据量?应该是在上线之前就考虑分区吧,而不是上线后考虑在线分区

四十亿条记录 太牛逼了

你哪个单位的?强悍 --reply by CSDN Study V1.0.0.3 (starts_2000)

真强大

强悍!

学习,想知道楼主是哪家公司的,做啥业务 数据量这么大 还有就是,怎么样看一个表有到大呀?

40亿?除了羡慕别无他语

可以做故障转移群集和负载平衡来保证安全性。至于存储的话可以用心跳线连一个专门的存储器来保障安全。其中存储器做radid 1 、

此贴必火,后排占座,观望解决方案。

我们的一个日指表,3个月也有1亿多行了 每个月4000万行左右。 分区是必须的 一般都是新建一张表分区好了,然后把数据签进去 分段迁 现在改方案了 事务表就保留3天的, 当天处理完就完事了, 然后把数据归到历史表去

这数据量够吓人的了

这样的数据量真是没必要,恕我直言,你数据结构没弄好,有些数据没有必要保存,只需要备份一下就可以。数据表里面有一定时间内数据就可以了。 比如我们的网站统计,就是保存的最近8天数据。其他数据备份之后都删除了。

一个应用,运行了1年,现在快1亿条记录了,分了100个区

考啊。40亿数据还能查啊。狂顶楼主!!

帮顶,严重关注。。。。。。。。。。。。。。

都是历史数据吧

估计是楼主的单位是电信运营商,

我是遇不上了哦学习一下看看。

接的的数据目前为止 还没有过100W的数据库,对楼主羡慕 嫉妒 恨中。。

引用 12 楼 kinsa 的回复:你胆子真大,在产品环境上做这么大改动。。。。。 建议新建一张分区表,在产品环境比较闲暇的时候将数据倒到新表中;最后用新表替换旧表。 这样做的好处是第一很安全,第二,速度肯定比你直接强加分区块,因为你在新表上可以先没有索引,数据全进去后再加上。缺点就是需要有空闲的空间。 一般这么大的产品库,绝对不推荐线上直接修改。成功了是侥幸,出问题是常态,出了问题你就要兜着走 顶下!

遇到同样问题 求解!

上一篇:大牛,请帮忙提点建议 200bean_sql]
下一篇:求SQL Server 2008安装包 100lailai186]

相关文章

相关评论