一般 DBA 最佳做法.docx
《一般 DBA 最佳做法.docx》由会员分享，可在线阅读，更多相关《一般 DBA 最佳做法.docx（24页珍藏版）》请在冰点文库上搜索。
一般DBA最佳做法
一般DBA最佳做法
成为特殊的SQLServerDBA的最佳做法
1.加入（或启动）本地SQLServer用户组（chapters.sqlpass.org）
2.加入SQL通（www.sqlpass.org）
3.参加每年至少一个专业的会议。
4.参加每年至少一个培训会议。
5.读SQL服务器上的至少四个书每年。
6.阅读免费的电子书，如何成为特殊的DBA
7.你可以说你的工作，特别是那些领域，没有人喜欢或想要的一切学习掌握。
8.志愿者在您的工作会使你已知在整个组织的新的和具有挑战性的任务。
9.安装SQLServer的笔记本电脑或台式计算机在家与实践学习新的SQLServer，尤其是SQLServer2008的方面。
10.参与SQLServer论坛（提问和回答）
1.www。
SQLServerC
2.
11.取得认证作为SQLServerDBA：
1.a.微软认证技术专家
（）
2.b.通过微软认证的IT专业人员（server.aspx#tab3）
日常
1.检查操作系统事件日志以及SQL服务器日志不寻常的事件。
2.验证所有预定的作业已成功运行。
3.确认备份已提出和成功保存到一个安全的位置。
4.监视磁盘空间，以确保您的SQL服务器将不会运行的磁盘空间不足。
为获得最佳的性能，所有磁盘应都具有15%或更多的可用空间。
5.全天，定期监视性能使用系统监视器和/SQL事件探查器跟踪。
6.定期监测，并找出阻塞的问题。
7.保持您的服务器，其中包括您识别并更正任何性能问题的说明文档所做的任何更改的日志。
8.创建SQLServer通知，通知您潜在的问题，并让他们通过电子邮件发送给您。
根据需要，采取行动。
9为了验证您可以将其还原.定期将备份还原到测试服务器。
你不需要还原所有备份的每一天，但经常做，确保您确信你有好的备份。
10.花一些时间学习作为DBA进一步你专业的发展新的东西。
安装
1.总是充分文档安装，以便在紧急情况下可以轻松地再现您的SQLServer实例。
2.如果可能的话，安装和配置您的SQLServer实例的所有一致后一个商定的组织标准。
3.不要在不使用它们，例如，Microsoft的全文索引、的实例上安装SQLServer服务报告
服务或分析服务。
4.为在Windows下运行的SQLServer的最佳性能，请关闭任何不需要的操作系统服务。
5.优化SQLServer的性能，要为献给你们的物理服务器仅运行SQLServer，连同没有其他应用程序的单个实例。
6.
7.为最佳的I/O性能，找到数据库文件（.mdf）和独立隔离磁盘访问模式的心轴上的日志文件（.ldf）。
8.如果tempdb将大量使用，请把它放在它自己独立的心轴上。
9.不要在域控制器上安装SQLServer。
10.将确保SQLServer安装NTFS分区上。
11.不要使用NTFS文件数据（EFS）加密和压缩对SQLServer数据库和日志文件。
升级
1.在升级之前运行SQL服务器升级顾问。
在执行升级之前进行必要的更改。
2.在升级您的生产服务器之前，执行测试升级你的测试SQL服务器。
和测试您的应用程序的新版本，也别忘了。
3.在升级之前，请确保您已回退到升级是有问题的情况下制定一个计划。
4.不要升级SQL服务器群集中的地方。
相反，重建他们新的硬件上。
5.如果从SQLServer的以前的版本升级时，您应在所有数据库中更新所有的统计数据。
这是因为在升级过程中不会自动更新统计信息。
安全
1.确保每个SQLServer，防止任何XX的用户，从物理上访问您的服务器的物理安全性。
2.只有在您的SQLServer实例上安装所需的网络库和网络协议。
3.尽量减少系统管理员允许访问SQLServer的数目。
4.作为数据库管理员，请与系统管理员特权，只在需要时登录。
单独为创建帐户时，系统管理员权限，则不需要访问SQLServer数据库管理员。
5.指定SA帐户密码非常晦涩，并永远不会用它来登录到SQLServer。
相反，使用Windows
身份验证访问SQLServer作为系统管理员帐户。
6.给用户最少的权限，他们需要执行他们的工作。
7.使用存储过程或允许用户访问数据，而不是让他们直接访问表的视图。
8.如果可能，使用Windows身份验证登录而不是SQLServer登录名。
9.所有SQLServer登录帐户都使用强密码。
10.不要授予公共数据库角色的权限。
11.移除用户登录不再需要访问SQLServer的Id。
12.使用撤消连接从来宾禁用guest用户帐户，从每个用户数据库。
13.不要使用跨数据库所有权链接，如果不是所需。
14.永远不要授予xp_cmdshell到非系统管理员的权限。
15.从生产的所有SQLServer实例中删除示例数据库。
16.使用Windows全局组或SQL服务器角色管理需要类似的权限的用户组。
17.避免任何SQL服务器上创建网络共享。
18.配置登录审核，因此您可以看到谁已经成功了，和失败，登录。
19.不要使用SA帐户或是系统管理员组的成员作为用于从应用程序访问SQLServer的帐户的登录Id。
20.确保您的SQL服务器在防火墙后面，和直接向互联网不会公开。
21.在SQLServer2005，较早前，要防止本地服务器管理员能够访问SQLServer的内置/管理员组中删除。
SQLServer2008中的内置/管理员组不存在的
默认情况。
22.每个单独的SQLServer服务，不同的Windows域帐户下运行。
23.只给SQLServer服务帐户的最低权利和运行该服务所需的权限。
在大多数情况下，本地管理员权限，则不需要，也不需要域管理员权限。
24.当使用分布式的查询时，使用链接的服务器而不是远程服务器。
远程服务器只存在的向后兼容性。
25.不要浏览web从生产SQLServer实例。
26.而不是安装的病毒和反间谍保护SQL服务器上，当用户活动较少的一天的会期从远程服务器执行扫描。
27.添加操作系统和SQLServer服务包和热修复补丁程序发布并进行测试，作为他们后不久
通常包括增强的安全功能。
28.加密所有SQLServer备份与第三方备份工具，如红门SQL备份临。
29.仅启用C2审核或通用标准法规，如有需要，如他们增加显著的性能开销。
30.考虑针对您的SQL服务器确定安全漏洞运行SQLServer安全扫描程序。
31.考虑启用SSL或IPSEC为SQLServer及其客户端之间的连接。
32.如果使用SQLServer2005/2008年，启用密码策略检查。
33.如果使用SQLServer2008在高安全性的环境，考虑实现透明数据加密保护机密数据。
34.如果使用SQLServer2005，不要使用SQLServer外围应用配置工具解锁您绝对不需要的功能。
35.如果使用的SQLServer2005/2008年并创建终结点，则只需要访问他们的登录连接权限授予。
明确拒绝不需要用户的终结点的连接权限。
维持就业
1.避免重叠的同一SQLServer实例上的作业。
理想情况下，每个作业应单独运行在不同的时间。
2.当创造就业机会，一定要包括错误捕获，登录作业活动，并设置警报，这样就可以立即知道当作业失败时。
3.创建特殊的SQLServer登录帐户的唯一目的是要运行作业，并将其分配给所有的作业。
4.如果你的工作包括TRANSACT-SQL代码，确保它优化有效地运行。
5.定期（每日、每周或每月），重新生成或重新组织索引的数据库中删除逻辑碎片和浪费的空间。
6.定期，作为所有您数据库上运行DBCCCHECKDB，您计划的数据库维护任务的一部分
验证数据库完整性。
7.避免一天忙时运行大多数DBCC命令。
这些命令通常是I/O密集型，并且可以降低，造成负面影响用户的SQL服务器的性能。
8.如果您很少会重新启动SQLServer服务，您可能会发现当前SQLServer日志变得非常大，需要很长的时间来加载和查看。
您可以关闭当前的错误日志，并创建一个新的运行
sp_cycle_errorlog或DBCC错误日志，以便将日志不会过大。
此设置为每周的作业。
9.编写脚本的所有作业，并将这些脚本存储在安全区域，因此他们可以使用，如果您需要重新生成服务器。
SQL服务器配置设置
1.SQLServer配置设置应维持在其默认设置。
只应由经验丰富的DBA明白的利弊进行更改这些设置的任何更改。
2.如果您使用的是32位版本的SQLServer，而如果使用4GB或更多的RAM，请确保您已正确设置的所有AWE设置。
3.在大多数情况下，"最大服务器内存"和"最小的服务器内存"的设置应由它们的默认值。
这是因为默认值允许SQL服务器动态分配的内存
最佳整体最优性能的服务器。
如果您使用此法则的例外情况可以会发挥
32位AWE内存或64位的内存，在您可能需要更改"最大服务器内存"金额小于物理服务器中的RAM量。
数据库设置
1.离开"自动创建统计信息"和"自动更新统计信息"选项对所有用户数据库。
只有在极少数情况下应这些处于关闭状态，，如果它们已被关闭，然后您必须手动更新统计信息你自己。
2.不要试图使用"自动收缩"数据库选项，因为它可以不必要地浪费SQLServer资源并有助于索引碎片。
相反，如果你需要收缩数据库，手动操作。
3.不要依赖于自动增长，自动管理您的数据库的大小。
相反，主动监视和更改数据库的大小，视情况所需。
只使用自动增长，以应付意外增长。
复制
1.复制需要应明确界定之前创建复制拓扑。
成功的复制可能很难，需要很多预规划。
2.在理想情况下，出版商、分销商和订阅服务器应在单独的物理硬件上。
3.创建、文档、和测试备份和还原策略。
还原复制的数据库可以很复杂，需要多大的规划与实践。
4.编写脚本作为灾难恢复计划的一部分复制拓扑，所以您可以轻松地重新创建您复制拓扑，如果需要。
5.使用复制的默认设置，除非您可以确保非默认设置会真正改善复制
性能问题或其他问题。
请确保您测试所有的更改，以确保它们像您期望的那样有效。
6.充分了解的添加或删除项目，更改发布属性，以及更改在已发布的数据库上的架构进行任何更改之前的含义。
7.定期对发布服务器和订阅服务器之间的数据进行验证。
8.定期监视复制过程和就业机会，确保他们工作。
9.定期监视复制性能和性能优化调试所需。
10.添加通知所有复制作业，所以您会收到通知的任何作业失败。
高可用性的最佳做法
通用高可用性
1.物理保护您的SQL服务器免受XX的用户。
2.物理上文档的所有您的SQLServer实例。
将纳入有效的更改管理。
3.始终使用SAN或直接连接的存储启用RAID阵列，用于存储您的数据。
4.使用SQLServer群集、数据库镜像或日志传送，以提供额外的容错能力。
5.复制不是从高可用性的角度看保护您的数据的有效手段。
6.确保您的整个IT基础设施是多余。
它只是一样强大最薄弱的环节。
7.始终使用服务器级硬件，并尽可能多地在同一硬件上实现标准化。
8.使用硬件和软件监视工具，所以你可以很快意识到第一次出现的问题。
9.彻底测试后，所有新的服务包和修复的OS和适用SQLServer。
10.跨列车工作人员，有很多人都能够对付几乎任何问题或问题。
灾难恢复
1.你必须创建灾难恢复计划，并包括您将需要重新生成您的服务器的每个细节。
2.如您的SQL服务器更改随着时间的推移，别忘了来更新您的灾难恢复计划。
3.写的灾难恢复计划，使任何懂得使用计算机的人将能够阅读并遵循它。
不要假定DBA将重新生成服务器。
4.全面测试您的灾难恢复计划每年至少一次。
5.审查所有的最佳做法您知道并酌情实现它们。
记住，作为数据库管理员，我们都组织的数据的监护人。
这是一种巨大的责任。
备份
1.所有的OLTP生产数据库应设置为使用完整恢复模式。
这种方式，您可以创建事务日志备份周期的基础上。
2.只要有可能，执行每日完整备份的所有系统和用户数据库。
3.对于所有的OLTP生产数据库，执行常规事务日志备份，每小时至少一次。
4.执行完整备份低用户活动期间为了备份对用户的影响降至最低。
5.定期执行测试以确保您的备份好并可以还原的备份恢复。
6.加密您的备份，以防他们应成为"损失"。
7.存储区进行异地备份，并在安全的位置。
8.如果使用SQLServer加密，请务必备份主密钥适当的服务、数据库主密钥和证书。
9.如果您发现备份时间长比您的备份窗口，或如果备份文件的大小以得太多
存储设备上的空间，请考虑第三方备份程序，如红门SQL备份临。
10.文档，循序渐进，要还原到相同或不同的服务器上的系统和用户数据库的过程。
你不想被查找此信息在紧急情况期间。
聚类
1.详细规划的每个SQLServer群集安装成功至关重要。
完全计划执行实际安装之前安装。
2.一个昂贵的群集是价值很小的如果支持基础结构还不是容错。
例如，别忘了电源冗余、网络冗余等。
3.运行只有单个实例SQL服务器的每个节点。
不管你有两个或八个节点群集中，作为故障转移节点离开至少一个节点。
4.群集节点必须不是域控制器，和所有节点都必须属于同一个域中，并应有
对两个或多个域控制器的访问。
5.所有群集硬件必须在MicrosoftWindows群集硬件兼容性列表，并且作为群集的一部分一起工作的认证。
6.由于聚类，不设计来保护数据（只有SQLServer实例），由使用共享的存储设备
群集必须纳入故障容错技术。
考虑日志传送数据库镜像或SAN复制来进一步保护您的生产数据库。
7.在安装Windows群集和SQL服务器群集之前，应确保所有驱动程序和软件已到-更新，包括最新的服务包或热修复补丁程序。
8.每个群集节点应具有相同的硬件、驱动程序、软件和配置设置。
9.光纤通道共享阵列在首选SCSI时建立群集，并且如果您在您的群集中包含两个以上的节点，则使用光纤通道。
10.在传统的群集中，仲裁驱动器必须在其自己的容错、敬业、磁盘500MB或更大
11.如果已安装群集，请彻底的每一个可能的故障情况下进行试验。
12.不要在SQL服务器群集上运行防病毒或反间谍软件。
13.在开始安装群集服务或SQLServer群集之前，确定您的虚拟名称和收集您的IP地址的时间提前。
这简化了安装时输入此信息的时候，
配置您的群集。
14.监视活动生产群集，每日，寻找任何潜在的问题。
定期测试，确保所有运作良好的生产服务器上的故障转移。
15.一旦你有一个稳定的SQL服务器群集运行，会非常的戒心它无论如何做任何更改。
SQLServer2005/2008年镜像
1.在主体数据库和镜像数据库应单独的物理硬件上和理想情况下，在不同的物理位置。
2.见证服务器应单独的物理硬件上和上一个单独的网络（最佳如果在第三的位置）。
3.初始数据库镜像设置应该做少忙时，因为安装过程可以产生负面影响
正在镜像的生产数据库的性能。
4.使用高可用性模式，只要有可能，和高性能模式，只在需要时。
5.为了便于管理，硬件，随着操作系统和SQL服务器的配置，应相同（至少是非常类似）两个服务器之间。
6.虽然不要求镜像的服务器、连接速度越快和更好的质量，更好的连接之间快速连接。
7.您会希望优化减少镜像进程本身引起的开销，尽可能多的镜像数据库的性能。
8.全面测试数据库镜像之前将它投入生产。
9.监视数据库镜像每日以确保它工作正常，并实现性能目标。
10.制定正式业务和恢复过程（和文档）支持镜像。
定期测试故障转移过程，以确保它正常工作。
日志传送
1.如果目前没有雇用聚类，或数据库镜像您的SQL服务器由于成本的考虑雇用日志传送，以提高您的高可用性。
它提供了低成本的合理的高可用性。
2.如果你利用SQLServer日志传送能力，要保留日志传送它自己，不在参与日志中的源或目标服务器上的航运的SQL服务器上的监控服务。
不只
这很重要的容错能力，但因为监测服务的日志传送招可以影响性能的源和目标服务器的开销。
3.监视日志传送每日以确保成功地工作。
4.了解你要知道要修复日志传送如果丢失生产和备份数据库之间的同步。
5.文件，并测试您的服务器恢复计划，因此可以将服务器出现故障的情况下。
性能调优的最佳做法
性能监视
1.定期监视系统性能，使用系统监视器或类似的工具。
2.定期监视系统性能，使用性能监视器。
使用性能监视器，为这两个实时分析和历史/基线调查分析。
3.如果运行SQLServer2005，SP2或以后，安装免费的SQL服务器的性能控制板。
它可以用于
实时监控和性能进行故障排除。
如果您使用的SQLServer2008，请考虑使用
性能数据收集器。
4.定期监察使用事件探查器或SQL跟踪SQL服务器活动。
请确保采取跟踪在一天的有代表性的典型活动的每个服务器上正在发生的时期。
当运行SQL跟踪
或事件探查器，不会收集更多数据比您需要收集，以便减少执行的开销
跟踪。
5.执行从不是您正在监视的SQLServer的计算机的性能监视。
在单独的桌面或服务器上运行监视工具。
硬件性能调优
1.尽管重型硬件可以帮助SQLServer的性能，应用程序和数据库的设计可以比硬件总体性能发挥更大作用。
记住这一点，作为赔了后坏的服务器硬件上并不总是能修复SQLServer的性能问题。
之前获得更快的硬件，请确保您已经彻底调谐你的应用程序、TRANSACT-SQL，和数据库索引。
2.在许多情况下，向服务器添加RAM是提高SQL服务器的硬件性能的最便宜和最快的方式。
但到SQLServer中添加更多的RAM之前,首先确保它将由SQLServer使用。
添加
并不意味着更多的RAM，SQLServer将始终使用它。
如果当前缓冲区高速缓存命中率是一贯
您和99%以上有好超过100MB的可用的RAM，您的服务器可能不会受益添加额外的RAM。
3.如果您的SQL服务器的总CPU利用率始终高于80%或更多，你需要更多的Cpu，更快的Cpu，或者您需要找到一种方法，以减少当前服务器上的负载。
4.如果逻辑磁盘：
%空闲时间）计数器是少于50%；与逻辑磁盘：
平均磁盘每秒/读取计数器或逻辑磁盘：
平均磁盘每秒/写入计数器是超过15毫秒，那么您很可能遇到的磁盘I/O性能问题，需要开始寻找解决办法。
5.不要必要实用程序的例外以外SQLServer的服务器上运行的任何应用程序。
6.NTFS格式的分区不应超过85%的能力。
例如，如果您有一个100GB的驱动器，它绝不应超过85GB更充分。
为什么呢？
NTFS需要工作，空间，当你超过85%的容量，NTFS变得效率较低和I/O可以忍受它。
此外，磁盘文件碎片实用程序需要至少15%的可用磁盘空间才能正常工作。
7.如果您的SQLServer数据库的经验大多是读取，然后RAID5阵列提供了很好的保护和足够的性能。
如果您的SQLServer数据库是主要的写操作，然后使用RAID10阵列的最佳保护和性能。
8.如果您的SQL服务器tempdb数据库使用频繁，考虑（例如，定位在其自己的磁盘轴的数组
RAID1或RAID10）。
这将允许更均匀地进行分发的SQLServer实例，减少磁盘I/O争用问题，并加快SQL服务器的总体性能的磁盘I/O。
9.更多的磁盘轴，您有一个数组中，将会更快的磁盘I/O。
请确保磁盘控制器可以处理
通过添加更多磁盘轴提供额外的I/O。
10.确保所有硬件正在都运行最新的、经批准的驱动程序。
索引
1.定期对当前事件探查器跟踪识别潜在缺失索引运行数据库引擎优化顾问。
2.删除从不使用的索引。
3.不要意外地创建冗余索引。
4.作为一个经验法则，每个表应该有至少一个聚集的索引。
通常，但并不总是聚集的索引应该是单调增加的列上——如标识列或增值的一些其他列——并且是唯一的。
在许多情况下，主键是理想列的聚集索引。
5.由于您只能创建一个聚集的索引，每个表，则需要额外的时间来仔细考虑将如何使用。
考虑对表，将使用和查询作出猜测，它查询（最常用之一运行对表，也许）的类型是最关键的如果此查询将受益最大
有聚集的索引。
6.创建一个复合的索引时，当所有其他因素都相等时，使最选择性的列的索引的第一列。
7.一般来说，尽可能保持作为窄索引的"宽度"。
这将减少索引的大小和
减少的磁盘I/O读取需要读取索引，大大提高性能。
8.避免将聚集的索引添加到一个GUID列（唯一标识符的数据类型）。
Guid占用16个字节的存储，标识列，该列可以使索引更大，这增加了I/O的读取，可以伤害比更多
性能。
9.索引应考虑经常访问该连接的所有列，凡，命令由集团、顶部和DISTINCT子句。
10.不要自动添加索引的表上因为这似乎是要做正确的事。
如果你知道他们会利用对表运行查询，只添加索引。
11.当创建索引，请尝试，如果可能使它们唯一索引。
SQLServer可以经常搜索通过
快于非唯一索引，因为唯一索引，每一行都是唯一的并且一旦找到所需的记录，SQLServer没有看任何进一步的唯一索引。
12.如果您执行定期在查询中的两个或多个表之间的联接，将优化性能，如果每个联接的列都有适当的索引。
13.不会自动接受默认值的索引的填充因子为100。
它可能或不可能最好地满足您的需要。
高填充因子是好的很少更改的数据，但高度已修改的数据需要较低的填充因子，
减少页拆分。
14.不要在索引OLTP表，作为您添加插入执行所需的时间的增加、更新和删除的每个索引。
有理想的索引数（用于选择）之间有细线和
尽量减少索引出现在数据修改过程中的系统开销的理想数目。
15.如果您知道您的应用程序将执行相同的查询反复在同一表中，则考虑在表上创建覆盖非聚集索引。
覆盖索引，
升级会员 