存储故障,导致数据库不可用

谢大脚

DELL的解释有点难以理解

SQLServer集群

切换到镜像数据库需要手工，DNS还需要手工。业务停止时间是多少？
如果采用SQL SERVER集群，就没有这么费事了。

hegenhua

DNS如何自动切换我不太清楚,不过在存储级坏掉, SQLServer集群应该是不起作用的吧.
   我们的架够确实存在很大的改进空间.比如,如果这个案例中,如果我们使用了见证服务器,并且在应用端的连接串中写有镜像服务器的域名,再加上
镜像与复制发布共存的技术,这次的影响就会小很多.  可惜呀,很多事情不是我一个DBA能决定的,比如,SQL server的集群,CTO就很反感,因为之前这个让他吃过
苦头,因而在提架构的时候直接就否决了.而且系统工程师也不愿意搭建域.当然,这个其实已经超出了技术的范畴了.
     至于存储是否是按最佳实践做的,我还是认为是的.因为我们之前有过使用ps 6000的经验,并且另一个实例就是跑在这个ps 6000上的,而且跑得很好.是双控+双Cisco交换机的,至于管理软件,是dell官方给的EqualLogic PS Series Group Manager,不知道这个是不是花好月圆说的那种软件

[ 本帖最后由 hegenhua 于 2011-2-18 21:59 编辑 ]

hegenhua

造成业务停机时间总共长达30分钟以上,所以说这次的处理方式是很不好的,或者说很不成熟.时间主要花在重起机器上,如果果断切换镜像,停机时间将大大减少,当然,这个架够还是不能做到零停机时间

hegenhua

这个机器我们已经弃用了,这个是我负责的DB第一次使用dell的产品,之前的都是HP的,没想到第一次使用就出问题. 所以现在大家一致决定不用他了,因为在故障的次日,这个问题又重现了. dell给出的故障原因说明,也是在次日再次发现问题后,把存储本身的日志给dell,dell在厦门的工程师看了后给出的. 更权威的说明也许要等到美国给出吧.当然,真正的原因dell未必会告知,因为目前dell给出的理由实在是不能令人信服,大家都觉得是在搪塞.如果是你说的没有按最佳实践做,dell的工程师到达现场检查后应该能发现(当然,这依靠工程师的水平和责任心),但dell并没有把责任归咎于没有合理部署存储的架构,而是给出了风扇停转造成故障的说法.

hegenhua

另外 64bit  sql 和windows开启和不开启AWE,这个有权威说法么,我现在确实不知道要不要开启好. 因为64位系统是可以直接寻址64GB物理内存的,但是那书上说,开启AWE并不是因为寻址的原因,而是因为微软的人发现,致使是在64位系统上,开启AWE也是有很大好处的.具体好处,我书不在旁边,具体不记得,下周一再把书上的原话发出来,供大家参考吧.

[ 本帖最后由 hegenhua 于 2011-2-18 22:22 编辑 ]

hegenhua

遗漏了一个重要信息,就是在第二天服务器能够正常重起后,我通过远程桌面连上去发现,存放tempdb的单独分区连驱动器号都没有了,原来是E盘,结果直接找不到了,后来是重新分配了驱动器号,sql server才能正常重起的.

SQLServer集群

号称SQL SERVER上的集群有多种，让你们CTO吃苦头的是哪种？
像你们这次停机事件，如果用的是真正的SQL SERVER集群，完全可以做到
零停机时间的，同时也是零数据丢失的。

SQLServer集群

如果你用的是无共享存储的那种SQL SERVER集群，那么这个存储坏了，另一个存储可以继续正常工作，
就不存在停机的问题了。

hegenhua

说来惭愧呀,这种集群我听都没听过呢,老大能简单单介绍介绍或是给点资料么,谢谢咯