hzh_hua168

NetApp最大的问题是一个卷内的数据达到卷容量的40%时,性能会马上下降很多,后悔啊!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

林肯

引用:

原帖由 hzh_hua168 于 2008-3-15 13:40 发表
NetApp最大的问题是一个卷内的数据达到卷容量的40%时,性能会马上下降很多,后悔啊!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

40％不至于把，个人认为有点诋毁之嫌

klin121628

40%太夸张了吧

thresh_freeman

引用:

原帖由 hzh_hua168 于 2008-3-15 13:40 发表
NetApp最大的问题是一个卷内的数据达到卷容量的40%时,性能会马上下降很多,后悔啊!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

你有什么后悔的？？？你是NetApp的用户吗!？

冬瓜头

vol使用率保持在低于90就可以保证性能。而且是纯使用率，不算reserve的。

cd_songkun

引用:

原帖由 xylonhong 于 2008-3-14 19:53 发表


是需要进行recover的。如果是用脚本方式实现备份那么就手工recover；如果是用是snapmanager for Oracle的话，可以自动实现recover.

谢了
请问一下 snapmanager for oracle 是内部完成了我们手工recover 的自动实现，还是利用其他的技术不用recover?
另外，snapmanager for oracle 是利用rman还是普通的sql脚本来实现的呢？

冬瓜头

我的理解是snapmanager触发db的checkpoint，尽力保证备份是一致状态的。但是能否用这个备份恢复数据库而不用任何redo和undo，就看db是否允许了，redo和undo就要有log。

cd_songkun

引用:

原帖由 冬瓜头 于 2008-3-17 12:59 发表
我的理解是snapmanager触发db的checkpoint，尽力保证备份是一致状态的。但是能否用这个备份恢复数据库而不用任何redo和undo，就看db是否允许了，redo和undo就要有log。

也是触发机制的话，那就可能是让oracle处于热备状态，需要 recover的可能性就很大了，snapmanager可能在内部利用了recover.

xylonhong

引用:

原帖由 hzh_hua168 于 2008-3-15 13:40 发表
NetApp最大的问题是一个卷内的数据达到卷容量的40%时,性能会马上下降很多,后悔啊!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

如果真的碰到这种情况确实很后悔。请问您的具体情况是什么，有没有开过case？有case号吗？

据我所知，如果用NAS，卷容量80-90以上的应用比比皆是；如果用SAN，基本上都是99%。

[ 本帖最后由 xylonhong 于 2008-3-17 23:29 编辑 ]

xylonhong

引用:

原帖由 cd_songkun 于 2008-3-17 10:35 发表


谢了
请问一下 snapmanager for oracle 是内部完成了我们手工recover 的自动实现，还是利用其他的技术不用recover?
另外，snapmanager for oracle 是利用rman还是普通的sql脚本来实现的呢？

snapmanager for Oracle 是用rman实现的。有兴趣可以参考附件。

smo-install.zip是安装和管理手册。
3452snapmanger-for-oracle.zip 是SMO的最佳实践。
3355oracle-flexclone-nas-san.zip 是脚本方式实现数据库的冷备或者热备，还有克隆。

[ 本帖最后由 xylonhong 于 2008-3-18 22:36 编辑 ]