对于初级DBA而言，他们遇到的最麻烦的事情之一就是维护其他人的应用的SQL Server。您做哪些操作才不会影响到这些应用呢?

　　首先，您应该非常熟悉SQL Server中的备份和恢复了;您总是可以在遇到问题时回滚一个修改。其次，要记录您所尝试的每一个修改，并且将您的试验限制为一次只作一个修改。这样即使出现问题，您也不需要花费大力气来修复它们。

　　下面是您可以放心去做的操作：

• 　　重组和重建搜索——优化SQL Server索引可以显著提升性能。记住，这个应用可能在重建过程中不能正常工作，而且它的运行速度肯定会变慢。
• 　　配置尽可能多的选项，除了兼容性配置——换句话说，您可以配置文件的自动增长和自动压缩，打开自动更新统计，等等——这其中大多数都是很有用的。
• 　　给服务器增加更多的内存——SQL Server很消耗内存，您给它再多内存也不为过。处理器也一样，所以您绝不应该配置处理器保护或内存限制。
• 　　备份和恢复数据库，即使是部分也行——这不会影响任何应用，而且备份再多也不为过。在真正重要的数据库中，我会使用普通的完全或差别备份，但是我更喜欢尽可能频繁地使用事务日志备份，因为它们是非常快速的，而且能实现非常粒度的备份。
• 　　使用SQL Server Profiler捕捉服务器流量进行分析——基本上，这种使用SQL Profiler的方式是被动的，所以应用程序甚至不会知道您在做什么。

　　接下来，让我们讨论一些您可以经常做而不会产生问题的操作。一个良好的应用是不会介意所有这些操作的，但是要记住，并不是每一个应用都开发得很好。

• 　　使用Database Engine Tuning Advisor添加或删除索引。添加索引通常不会给应用造成影响，但是有一些应用可能会使用名称来引用一个特定的索引。这意味着如果您删除一个索引，就可能会产生问题。

　　虽然不应该直接使用名称来引用索引;但是有一个正当的原因可能导致应用需要以硬编码方式引用一个索引，那就是当一个应用使用自己的维护程序进行每个索引的重组和重建时。

• 　　将数据库对象划分为多个数据库文件，这样您可以将不同的文件存储在不同的磁盘上以提高性能。

　　我并没有发现很多地方需要使用这种方法，因为现在我们经常将文件存储在RAID阵列中。数据库的物理布局是与逻辑结构分离的，所在应用程序一般不关心文件的物理位置——当然，除非应用有自己的备份程序，这时它可能会依赖于特定的文件或文件组名。

　　对于大多数应用，您几乎可以做大多数您想要做的性能调优或维护任务，而应用不会关心这些操作。质量不是很好的应用可能会依赖类似于具体索引名称的东西，这时您可能需要向供应商询问为什么他们需要这样做。