数据库服务器构建和部署检查列表详解

前言

我们可能经常安装和部署数据库服务器，但是可能突然忘记了某个设置，为后来的运维造成隐患。下面是国外大牛整理的的检查列表。

其实也包含了很多我们平时数据库配置的最佳实践。比如TEMPDB 文件的个数，比如数据库文件，日志文件如何存放，最大内存的设置等等。如果有补充的欢迎留言

正文

1. 机架和电缆服务器

确保每个电源插入不同的电源电路

果可能，请确保网络电缆已插入不同的网络交换机

2.SQL Server服务和SQL Server代理服务的使用域帐户。

在SQL Server 2012安装期间，您将需要知道这些帐户的用户名和密码

让这些帐户使用永不过期的密码

3.检查服务器上的主BIOS设置

启用超线程和turbo-boost（是一种超频技术，提升最多10%的性能）

电源管理应设置为操作系统控制

禁用内存测试

4.在服务器上安装Windows Server 2012 R2 Standard Edition

使用集成RAID控制器在RAID 1中使用两个内部驱动器

如有可能，请考虑使用SSD

如果使用SSD，则不需要对其进行碎片整理

为C：驱动器创建一个单独的分区

将Windows页面文件大小更改为16GB，并防止C盘

将Windows电源计划更改为“高性能”

在服务器上运行CPU-Z以确认处理器全速运行

将光盘驱动器的驱动器号更改为Z：

5.将服务器上的NETBIOS名称更改为所需的服务器永久名称

6.使用Windows Server 2012 R2自带功能安装.NET 3.51

7.在服务器上安装Microsoft Update

这是Windows Update的超集

8.在服务器上安装所有Microsoft和Windows更新

这可能需要几轮才能获得所有必需的更新

9.对C盘进行碎片整理

使用使用计划任务每周自动对C盘碎片整理

不允许将新驱动器自动添加到计划中

10.创建一个具有正确DNS和默认网关信息的静态IP地址

11.将服务器加入到相应的Windows域

12.在服务器上激活Windows

13.在服务器上安装最新版本的Dell OMSA （这个东西我没用过）

14.下载最新版本的Dell Server Update Utility（SUU）

将.iso装入SUU，并运行SUU

这将确保您具有服务器的最新固件和驱动程序

15.使用Dell OMSA为LUN创建RAID阵列

创建一个LUN，然后转到逻辑磁盘管理器创建/格式化驱动器

II。按照下面显示的顺序创建阵列和LUN

戴尔OMSA中的一般PERC设置

对RAID 10阵列使用智能镜像

II。没有预读高速缓存

III。启用回写缓存

IV。应启用缓存策略

v。使用64K分配单元

16.使用Windows逻辑磁盘管理器创建逻辑磁盘

使用OMSA创建阵列后，打开磁盘管理器

您将看到“初始化磁盘”对话框

确保使用GPT分区样式

17.检查下，保证新的逻辑驱动器在Windows资源管理器中都能够看到

18.在安装SQL Server 2012之前，把所有需要的逻辑驱动器都创建上

19.使用CrystalDiskMark测试每个逻辑驱动器的性能

20.使用SQLIO测试每个逻辑驱动器的性能

21.在每个驱动器上，创建下面的文件夹

数据驱动器：SQLData

日志驱动器：SQLLogs

TempDB驱动器：TempDB

备份驱动器：SQLBackups

22.使用组策略编辑器（GPEDIT.MSC）将这些Windows权限授予SQL Server服务帐户

执行卷维护任务

锁定内存页面

23.安装SQL Server 2012企业版

确保没有待处理的重新引导，否则SQL Server 2012将无法安装

仅安装此实例所需的SQL Server 2012组件

C。使用混合模式认证

将sa密码设置为强密码

II。将自己添加为SQL管理员

III。添加任何需要成为管理员的其他DBA

对于SQL Server服务帐户使用域账户

使用对应的域账户作为SQL Server代理帐户

F。将SQL Server代理服务设置为自动启动

G。将默认目录设置为相应的驱动器号和路径

I.用户数据库目录：P：\ SQLData

II.用户数据库日志目录：L：\ SQLLogs

III. Temp DB目录：T：\ TempDB

IV。 Temp DB日志目录：T：\ TempDB

v。备份目录：N：\ SQLBackups

24.安装SQL Server 2012最新 Service Pack

25.安装SQL Server 2012 最新的累积更新6

累积更新可从此位置获得：

http://support.microsoft.com/kb/2874879/en-us

安装后手动对C：驱动器进行碎片整理

如果您使用的是SSD，则不需要这样做

26.更改SQL Server 2012实例级属性

a. 启用optimize for ad hoc workloads

这将允许SQL Server在第一次执行时使用较少的内存来存储临时查询计划

b.设置最大并行度设置为服务器上NUMA节点中的物理核心数

c.启用默认备份压缩

这将为所有数据库备份默认使用SQL Server备份压缩

d.在SQL Server配置管理器中添加跟踪标志3226作为启动选项

这将阻止在SQL Server错误日志中记录成功的数据库备份消息

e .在SQL Server配置管理器中添加跟踪标志1118作为启动选项

这将有助于缓解tempdb中的配置争用

f. 在实例上启用数据库邮件

用于SQL Server代理警报和SQL Server代理作业失败时邮件通知

G。将Max Server Memory设置为适当的非默认值

值取决于服务器中可用的物理内存量

它还取决于安装的SQL Server组件

II。以下是一些示例值：

1.96GB总RAM：将最大服务器内存设置为87000

2. 64GB总RAM：将最大服务器内存设置为56000

3. 32GB总RAM：将最大服务器内存设置为27000

H。在T：\ TempDB目录中额外再创建三个TempDB数据文件。总共4个tempdb文件（不需要一开始就和CPU个数对齐）

所有TempDB数据文件的大小应为4096MB

将自动增长设置为1024MB

II。 TempDB日志文件应为1024MB

27.确认您可以从域上的其他计算机ping通 SQL Server计算机

28.使用SQL Server 2012 Configuration Manager，确认实例启用了TCP / IP

29.确认您可以使用其他计算机上的SSMS远程连接到SQL Server实例

30.在实例上创建一个SQL Server操作员

使用DBAdmin与电子邮件地址dbadmin@yourcompany.com

31.确认数据库邮件正常运行

右键单击数据库邮件并发送测试消息

32.配置SQL Server代理邮件以使用数据库邮件

33.为以下错误创建SQL Server代理警报：

a . YourServerName Alert - Sev 19错误：资源中的致命错误

b. YourServerName Alert - Sev 20错误：当前进程中的致命错误

C。 YourServerName Alert - Sev 21错误：数据库进程中的致命错误

d。 YourServerName Alert - Sev 22错误致命错误：表完整性可疑

e. YourServerName Alert - Sev 23错误：致命错误数据库完整性可疑

f。 YourServerName Alert - Sev 24错误：致命的硬件错误

g。 YourServerName Alert - Sev 25错误：致命错误

h。 YourServerName Alert - Error 825：Read-Retry Required

i。 YourServerName警报 - 错误832：常量页面已更改

j.YourServerName警报 - 错误855：检测到不可纠正的硬件内存损坏

k。 YourServerName警报 - 错误856：SQL Server已检测到硬件内存损坏，但已恢复该页面

34.这里提供了创建这些SQL Server代理警报的通用脚本：

确保每个代理警报都有响应来通知DBAdmin操作员

35.创建一个名为Nightly Free System Cache的SQL Server代理作业，运行此命令：

DBCC FREESYSTEMCACHE ('SQL Plans');

每天晚上在凌晨12:00运行

36.下载最新版本的Ola Hallengren的SQL Server维护解决方案脚本：

http://ola.hallengren.com/

连接到实例时打开MaintenanceSolution.sql脚本

将@BackupDirectory变量修改为N：\ SQLBackups

II。运行脚本创建十一个新的SQL Server代理作业

III。对于每个作业，如果作业发生故障，请转到“通知”属性窗口，并将作业通过电子邮件发送给DBAdmin组

IV。对于每个作业，创建一个运行时间的计划。

v。这是一个建议的工作时间表：

CommandLogCleanup星期日上午12:00

2. DatabaseBackup - SYSTEM_DATABASES - 完整的每日11:55 PM

3. DatabaseBackup - USER_DATABASES - DIFF Daily at 12:00 PM

4. DatabaseBackup - USER_DATABASES - 上午12:00时全天

5. DatabaseBackup - USER_DATABASES - 每小时记录一次

DatabaseIntegrityCheck - SYSTEM_DATABASES星期六上午7:55

7. DatabaseIntegrityCheck - USER_DATABASES星期六上午8:00

8. IndexOptimize - USER_DATABASES星期日下午8:00

9. 文件清理 星期日上午12:00

10.sp_delete_backuphistory星期日上午12:00

11.sp_purge_jobhistory 星期日上午12:00。

总结

对于个人认为比较重要的最佳实践我都用红色的标注了。不过上面的启用超线程和turbo-boost

我觉得要根据客户的实际情况，如果 客户的系统能够用上这些多余的逻辑CPU，那么才应该开启超线程。根据经验通常OLTP系统开启超线程是比较有好处的。但对于某些报表查询，可能开启超线程反而会有不良影响。
详细可以参考：https://blogs.msdn.microsoft.com/slavao/2005/11/12/be-aware-to-hyper-or-not-to-hyper/

tempdb文件个数

我们知道增加tempdb数据文件可以减少PAGELATCH争用 ，按照以前的最佳实践是和CPU内核数对齐。但是现在已经做了优化，不需要一来就设置那么多

MBR and GPT

GPT意为GUID分区表。（GUID意为全局唯一标识符）。这是一个正逐渐取代MBR的新标准。它和UEFI相辅相成——UEFI用于取代老旧的BIOS，而GPT则取代老旧的MBR。之所以叫作“GUID分区表”，是因为你的驱动器上的每个分区都有一个全局唯一的标识符.在MBR磁盘上，分区和启动信息是保存在一起的。如果这部分数据被覆盖或破坏，事情就麻烦了。相对的，GPT在整个磁盘上保存多个这部分信息的副本，因此它更为健壮，并可以恢复被破坏的这部分信息。GPT还为这些信息保存了循环冗余校验码（CRC）以保证其完整和正确——如果数据被破坏，GPT会发觉这些破坏，并从磁盘上的其他地方进行恢复。而MBR则对这些问题无能为力——只有在问题出现后，你才会发现计算机无法启动，或者磁盘分区都不翼而飞了.
总之，GPT更先进，更健壮，推荐使用GPT

关于其他选项没什么争议。应该尽量遵守的。

以上就是本文的全部内容，希望对大家有所帮助。感兴趣的朋友可以参阅：oracle 数据库启动阶段分析 、关于数据库连接池Druid使用说明 、浅谈oracle rac和分布式数据库的区别 等，有什么问题可以随时留言，欢迎各位到本站交流讨论。