【问题标题】:Database never maintained数据库从未维护
【发布时间】:2014-03-31 07:22:37
【问题描述】:

由于供应商应用程序对新版本的限制,我最近刚从 SQL2000 迁移到 SQL2005 的新客户端。供应商应用程序仅与 SQL2005 兼容。 我发现 DB 从来没有制定过维护计划:它大约有 14 年的历史,一直在运行,幸运的是,一直在备份(每日完整备份、4 小时差异和 10 分钟事务日志备份)。

乍一看,DB 分为 4 个 mdf 文件(10Gb、30Gb、2Gb、2Gb)和一个 35Gb 的 ldf 文件。 ldf 相当大,因为事务日志最大为 100 mb。对于那些年办公室人员所说的,有2-3次大删除,但他们不知道其他任何事情。服务器有点旧(IBM x346、8Gb Ram 和只有 70gb 的可用硬盘空间),运行 W2003 R2 32bit 和 /pae 和 SQL2005 和 AWE。

乍一看索引碎片很大。

在这种情况下开始“复活”的最佳做法是什么:-)?

【问题讨论】:

  • 开始“不在程序员论坛上提问”。这是 dba 的一个特殊区域,这纯粹是管理性的 - dba.stackexchange.com。投票关闭以将其移至那里。
  • 很抱歉。不知道有那个特定区域。

标签: sql-server sql-server-2005 maintenance transaction-log ldf


【解决方案1】:

对数据库的使用方式一无所知,无法真正评论备份策略,除了有备份策略很好:) 不过感觉还可以。

首先将备份恢复到另一台机器(以验证备份是否确实有效),然后在其上运行 DBCC CHECKDB(在恢复的副本上)。

启用 PAGE CHECKSUM 和 BACKUP CHECKSUM:

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/29/enabling-checksum-in-sql2005.aspx

实施 Ola Hallengren 的维护解决方案:

http://ola.hallengren.com/

运行 Glenn Berry 的诊断脚本并在有任何可疑情况时报告:

http://sqlserverperformance.wordpress.com/2014/03/11/sql-server-diagnostic-information-queries-for-march-2014/

我不会太在意ldf的大小,只要存储空间不是问题。

你现在有什么急事要处理吗?

【讨论】:

  • 首先感谢您的帮助。我认为存储空间将在几个月后成为问题,我会为那一刻做好准备。对于我读到的 Ola 维护解决方案将处理索引情况,对吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-07-09
  • 2010-10-18
  • 2015-09-16
  • 1970-01-01
相关资源
最近更新 更多