ORACLE 10g基于NFS文件系统RMAN备份优化－公众版

ice.xie

說實話,rman+nfs的效果並不讓人滿意,我之前用這種方法就經常出問題.
還請piner大大研究過好幾次,我不推薦使用這種方法.
至於mount  nfs的時候加參數則是必須的,詳細的大家可以看看metalink
424785.1        Receiving error Ora-27054 When Running Rman With NFS

我個人比較喜歡先備份到本地,再利用linux的resync服務,同步到另一臺.速度很快.

lfree

我的测试没有问题，就是速度不够快。

实际上11g以后支持bzip2压缩，这个感觉压缩有点慢。但是文件很小。

asasjun

要下下来好好的学一下了。

iamclq

好东西，谢谢楼主分享

cow977

原帖由 zongyongchun 于 2008-8-29 17:34 发表
不好意思～发完贴才去看了你的pdf～

原来是自己做的NAS，200G的容量，40G的数据量，不知道你的RAID5是硬件RAID，还是软RAID?

有没有试过不压缩会是多大？耗时多久？

平均算下来：40×1024 MB   /   （（6×60+40）× 60 ）Sec   =   1.7 MB/s

这个速度？？我想你可以做的更好！

如果我的话让你感到不舒服，请不要怪我说话太直，如果我算错了，请你告诉我。

压缩也是要时间的。
压缩可以减少数据量，但却增加了处理时间。

iamclq

学习了，谢谢

xiaodong_1567

不错，学习～～～

shahand

原帖由 zongyongchun 于 2008-8-29 17:34 发表
不好意思～发完贴才去看了你的pdf～

原来是自己做的NAS，200G的容量，40G的数据量，不知道你的RAID5是硬件RAID，还是软RAID?

有没有试过不压缩会是多大？耗时多久？

平均算下来：40×1024 MB   /   （（6×60+40）× 60 ）Sec   =   1.7 MB/s

这个速度？？我想你可以做的更好！

如果我的话让你感到不舒服，请不要怪我说话太直，如果我算错了，请你告诉我。

应该参考dd的速度

16k*65536/10s

看看，近百兆的速度。

wwwlh

原帖由 zongyongchun 于 2008-8-29 17:34 发表
不好意思～发完贴才去看了你的pdf～

原来是自己做的NAS，200G的容量，40G的数据量，不知道你的RAID5是硬件RAID，还是软RAID?

有没有试过不压缩会是多大？耗时多久？

平均算下来：40×1024 MB   /   （（6×60+40）× 60 ）Sec   =   1.7 MB/s

这个速度？？我想你可以做的更好！

如果我的话让你感到不舒服，请不要怪我说话太直，如果我算错了，请你告诉我。

讨论而已，我不会说别人的不是的
数据不压缩的话，已经接近290G
我的是放在一台PC-SERVER上的硬件RAID5
主要瓶颈在NFS文件系统上上，如果FTP的话，我做过290g大约需要3个小时，传输速率只能达到每秒
290×1024/3*3600=27.4MB/S
大家可以去试，1000M的网络实际传输最多80M就不错了
另外讲一点网络速率和传输速度的问题,呵呵我先是成为了CCNP，然后才是一个DBA

注意下面B－字节 b－位的区别 1B=8b,不理解的回去看计算机基础知识
1000M网络速度是指bit位的速度，理论网络传输速度上限是1000/8=128MB/S
可是这个速度是在物理层的理论值,呵呵我们要用的TCP/IP协议和FTP协议中间还有好多个协议层.
基于种种原因的考虑,每个协议层都要在数据包头封装一些东西,因此我们一般只能实现用10个字节来描述一个有效的数据
换算成传输速率就是1000/10=100MB/S
另外要考虑的一个事情是,你的应用是否是单向传输的业务,如果是的话,你最多只能实现100MB/S的速率,如果是双向对称传输的协议话呵呵,你的最大传输速率是100/2=50MB/S
这样的业务典型的就是双向的视频会议.
回到FTP传输的问题来,大家要问,FTP不是单方向传输的吗?为何我们经常只能实现30-40MB/S,最多不过60-70MB/S的速度,不对FTP是一个典型的不对称的传输协议,在我们下载的时候,可能下载流量占用了大部分的带宽,但是大家要注意到,FTP必须在服务器和客户端之间传输一些控制命令和交换一些数据请求包什么的,典型的上行流量大概能占用到整个传输10%,呵呵我们上面提到的100M/S的理论上限一下少了10M/S变成90M/S.
接着你又问了不还有90M/S吗?剩下那些速度都在那里产生瓶颈了,呵呵,让我慢慢道来
1.你的客户端和服务器最少都可能在同一台千兆交换机上吧,对不起,交换机会对数据传输产生一定的时延,因为千兆交换机一定是基于存储转发的,这个时延根据厂商算法和芯片的不同,可以造成传输速率下降,下降的幅度在2-10%之间变动,按照平均5%来计算吧,现在是多少了,90*0.95=85.5MB/S
2.服务器的千兆网卡和客户机的千兆网卡是接在那里的,你一定会说是在主板上集成的,没错,可是你知道它们到底接在那里吗?呵呵告诉你如果是接在主板上的一定是在南桥总线上的,典型的南桥总线是2GB/S(INTEL ICH8),没完这南桥总线不是千兆网卡独享的,是N多设备共享的,网卡,IDE硬盘接口/SATA接口,声卡等等一大堆东西,一般来说,网卡能达到理论带宽的90%就很不错了,呵呵再算一下,85.5*0.9=76.95MB/S
3.没完,FTP协议使用网络传输的数据从那里来?呵呵从硬盘来,到那里去?到硬盘去.这一来一去有个问题,硬盘并非能全速达到理论传输上限,哪怕你组成一个很快的RAID 0,硬盘传输数据都会有一点延迟,这个延迟来自于硬盘的传输原理,FTP一个大文件要在磁盘中移动磁头,找到这个数据块,然后读到内存中,有个5-10%的延迟不为过吧,写入同样,要找到空闲的块,同样可能有5-10%的延迟,取小一点,两边都按5%来计算,呵呵10%的延迟呀,现在你一定冒汗了,降到多少了?76.95*0.9=69.255MB/S
4.数据仅仅是到了内存,还没传输到网卡上,这时后,CPU肯定要处理,DMA通道也要处理,内存虽然读得飞快,网卡处理芯片要处理数据,这一大堆玩意虽然都很快,可是同样有延迟,考虑到这些因素,降个5%是很正常的,实际上,基于内存的网络传输速率测试不比硬盘快多少,这时的速率是69.255*0.95=65.79MB/S
这个速率我想大多数使用过千兆网络FTP传输的人,都见过这样的速度吧,一般来说千兆网络FTP传输很难超过80M/S
5.操作系统,FTP SERVER 和FTP CLINET的软件处理能力的问题,这个是一个更复杂的问题,但是可以肯定的是不同的平台和版本,性能差异可能巨大,我用过N多的FTP SERVER和FTP CLINET,访问同一个内部服务器的时候,性能差异巨大,相同的环境下,例如IIS 6的SERVER 配合WINDOWS FTP命令能到40-50MB/S,换一个LINUX下的LFTP客户端就能达到60-65MB/S的性能.
这上面还有一个因素,如果遇到交换机繁忙,或者交换机交换容量不够的情况下,上面许多因素再打大一点折扣,例如磁盘延迟很大,上面的数字还要大大打个折扣.不幸的是我们的许多系统大部分的部件,经常处于繁忙的阶段,上面的数字最多只能实现80%的效能,呵呵所以大多数的千兆FTP传输在30-40MB/S间波动是很正常的.

[ 本帖最后由 wwwlh 于 2008-9-20 23:53 编辑 ]

BTxigua

原帖由 wwwlh 于 2008-8-13 22:51 发表
大家经常使用NFS做RMAN的备份，但是想过没有RMAN和NFS其实有好多东西可以优化的呵呵，我的一次RMAN备份的优化总结，从22个小时到6个半小时的经历，希望能给大家帮助，除了没有真实的数据库的信息外，其它全部来自实际的，呵呵由于篇幅的原因，有些效果不明显的东西的过程就没有加以罗列了呵呵。

还可以考虑在网络上的优化。
网络优化除了MTU之外，还有几个比较重要的地方可以优化。
en2: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
        inet 211.11.1.103 netmask 0xffffff00 broadcast 211.11.1.255
         tcp_sendspace 1048576 tcp_recvspace 1048576 rfc1323 1


上面描红的字段。可以增加tcp接收和发送的缓冲空间大小，启用rfc1323支持，增大tcp的窗口尺寸。对于千兆网络，传送速度应该时比较大的提高的。我在做同步的时候，速度可以达到85M/s。