本人新书上市，请多多关照：《SQL Server On Linux运维实战 2017版从入门到精通》

在这里插入图片描述

在安装SQL Server On Linux的过程中，发生了什么事情？可能大部分读者或者用户并不关心，但是作为本人深入研究而言，有必要进行了解。这一篇本身应该放在安装后接着讲，但是由于某些细节本人还没找到相关资料去研究，所以暂缓了文章的进度。那么这篇文章就从DBA的角度去看一下安装过程发生了什么，同时了解一下某些文件的位置。

安装的内容

在Windows平台，我们习惯了使用.exe或者.iso作为安装介质进行安装，但是在Linux平台，更常用的是二进制文件（binary files），当然还有其他方式。在SQL Server 2017、2019中（这里不讨论SQL 2016的Linux版本，因为它不算正式版本），其二进制文件存放在/opt目录下，它的应用程序文件包含数据库文件则存储在/var/opt目录下。下面介绍一些重要的目录：

/opt/mssql

首先是/opt/mssql，这个目录下包含了bin和lib两个目录：

在这里插入图片描述

先说bin目录，bin目录包含了sqlservr二进制文件、mssql-conf bash脚本还有一系列支持dump 文件诊断的shell脚本。

在这里插入图片描述

接下来是lib目录，lib目录下包含的内容比较多：

在这里插入图片描述
但是从种类来说却不多，主要有：

lib*.so文件：供sqlservr使用的共享库文件。
mssql-conf目录：包含了被主mssql-conf bash脚本调用的一系列python脚本。
.sfp文件：这些是SQL Server on Linux架构中的特殊文件。以二进制形式存储，包含了SQLPAL用于运行SQLSERVR.exe、各种DDLs、libOS所需的二进制文件，还有其他一些二进制文件。另外值得注意的是.sfp文件还包含了SQL Server的系统库。

/var/opt/mssql

这个目录对于DBA而言极其重要，因为默认情况下，你的SQL Server用户数据库都在这里。

data目录：包含系统数据库文件、用户数据库的数据及日志文件
log目录：不要以为是数据库的日志文件，其实它最重要的是存放了ERRORLOG文件，还有其他以故障侦测为目的文件。
mssql.conf文件：这是一个文本文件，存储mssql-conf脚本的最新配置。mssql-conf脚本把配置写入这个文件，当SQL Server启动时会读取这文件并根据文件内容修改当前SQL Server配置（这也是为什么使用了mssql-conf命令做了修改后需要重启SQL Server服务）。

在这里插入图片描述

其他文件

在SQL Server安装过程中，还会安装其他的一些文件，包括：

EULA文件：END USER LICENSE AGREEMENT，最终用户许可协议。存储在/usr/share/doc/mssql-server
SQL Server及mssql-conf相关的man内容，存储在/usr/share/man/man1目录下。

安装后的内容

在安装结束后，在LOG目录下会出现这些内容，LOG目录默认在/var/opt/msssql/log中：

errorlog*：这个如果是常年使用SQL Server的用户来说应该很熟悉了。错误日志（但是并非仅记录错误信息），是SQL Server的从启动到日常运行过程中记录重要信息的文本文件。是快速定位故障或性能问题的首要切入点。在SQL Server启动时，会先把前一个ERRORLOG文件复制到ERRORLOG.文件中，然后创建一个新的ERRORLOG文件。SQL Server默认只保留最新的6个错误日志。如果使用cat /var/opt/mssql/log/errorlog来查看错误日志，大概是下面这个样子，不过习惯于使用SSMS的我而言更倾向使用SSMS来阅读：

在这里插入图片描述

log*.trc：.trc是在SQL Server 2008 R2之前，用于收集SQL Server运行情况的主要工具——SQL Trace/Profiler所产生的文件。但是微软已经强烈建议不要再使用Trace功能，取而代之的应该是扩展事件（Extended Events，xEvents）。
system_health*.xel：这些文件是被system Health事件会话（自带的扩展事件之一）调用，包含了SQL Server健康情况的重要信息。

安装后配置

不管是Windows还是Linux平台上的SQL Server，安装成功之后，要进行一些交付前配置，这些配置通常是为了获取更好的安全性和性能。具体的细节在后续会陆续介绍。这里先做一个简介。
配置工作需要一些工具，这些工具有自带的T-SQL命令、Linux平台特有的mssql-conf，首先介绍一下Linux平台的mssql-conf。

使用mssql-conf进行配置

在Windows平台上，有一个称为配置管理器的图形化工具用于配置一些不适合或者无法使用T-SQL命令实现的配置，如SQL Server服务账号的选择、TCP/IP配置等等。而在Linux平台上，由于通常使用的都是命令行方式，所以需要有一个工具来提到这部分的功能，所以mssql-conf就应运而生。我们可以使用sudo /opt/mssql/bin/mssql-conf --help来查看这个命令的说明。
其中最常用到的选项是set/unset和traceflag这三个：

set：对配置项进行值的修改。很多配需要求重启SQL Server服务。一般建议每一次配置都要重启而不是等到完全配置好再重启，以免出错后很难定位。详细的列表可以见官方文档使用 mssql-conf 工具配置 Linux 上的 SQL Server。在这些列表里面，最常用的首先是配置SQL Server Agent随着SQL 服务启动，因为过去这个操作是有配置管理器来完成，在Linux平台则需要使用mssql-conf来完成。

sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true

除此之外，还有一些配置可能会用到：

filelocation.defaultdatadir ：新数据库的默认数据文件存放路径，默认为/var/opt/mssql/data。如果修改这个配置，记得对mssql这个组及用户进行授权。
filelocation.defaultlogdir ：新数据库的默认日志文件存放路径，默认为/var/opt/mssql/data。如果修改这个配置，记得对mssql这个组及用户进行授权。在生产环境下，企业对数据的存储路径可能会有要求，这个时候这两个命令就可以起到作用。
filelocation.errorlogfile ：ERRORLOG和其他日志文件（非数据库的ldf）默认存储路径，初始值为/var/opt/mssql/log，修改该值同样需要授权。
network.tcpport ：SQL Server的默认TCP端口是1433，由于过于广为人知，对有安全要求的企业来说通常会改掉，但是修改该值（假设改成1401），那么在后续连接时必须制定端口，如：sqlcmd -Usa -S localhost,1401。同时要切记一并检查防火墙的策略是否对新端口开放，否则也会连接不上。
filelocation.defaultbackupdir ：这个从名字上就可以猜到是默认的备份路径，在/var/opt/mssql下。如果在使用T-SQL或者其他工具进行数据库备份时不显式指定备份路径，则会备份到这个目录下。通常在正式环境下会修改路径指向专用的备份设备或者与数据库隔离开来。同时因为这个值是在安装过程就内置指定没有修改的地方。所以后期修改几率很大。

提醒一下，上面的配置项在Windows平台也是需要考虑的内容。

unset：set的反向操作，用于“恢复默认值”。好处在于你不用记住原有的值比如默认路径在哪里，直接unset即可。很多unset操作需要重启服务但是却不一定会有提示你这样做，建议set操作要求重启的话，unset也要重启。
traceflag：跟踪标记可以影响SQL Server的各个层面（实例级别、库级别、查询级别等），我们最最常用的跟踪标记就是对死锁的跟踪，一般使用1222这个即可，关于跟踪标记的说明可见官网DBCC TRACEON - 跟踪标志 (Transact-SQL)

sudo /opt/mssql/bin/mssql-conf traceflag 1222 on

SQL Server实例配置

前面提到的算是在SQL Server“外部配置”，那么接下来就是对SQL Server进行内部配置，主要针对实例级别的配置。这里跟操作系统平台的关联就相对较小了。这部分主要使用T-SQL即可完成，包括系统存储过程sp_configure及ALTER SERVER CONFIGURATION命令。但是需要提醒的是大部分配置修改操作都需要system administrator权限来执行。

sp_configure

作者印象中（不去深究了），从SQL 2008开始，很多SQL Server的配置项被定义为“高级配置”，如果不使用sp_configure把它先开启（修改show advanced options 的值为1），是无法继续下去的。具体的清单可以参阅官方文档：sp_configure ，在后续的过程中也会多次使用到，这里就不多说了。

ALTER SERVER CONFIGURATION

sp_configure在修改单值配置时是很有用的，但是一些服务器范围的配置可能需要进行较为复杂的修改，这时候ALTER SERVER CONFIGURATION就有用处了。比如可能不常用到的处理器掩码（PROCESS AFFINITY），由于通常数据库服务器是专用的，且只用于一类负载（OLTP/OLAP），所以对CPU的使用没有太多讲究，但是某些情况下服务器可能会混用OLTP和OLAP，那么这个时候CPU的分配就有所讲究。比如我们需要设置SQL Server进程仅在NUMA节点0上进行调度，可以使用下面T-SQL命令完成：

ALTER SERVER CONFIGURATION SET PROCESS AFFINITY NUMANODE=0

Windows的配置在Linux上的修改

在Windows平台中，SQL Server需要进行某些配置，那么相对而言，在Linux平台下，有些配置是通用的。但是也存在某些配置是不通用的，下面我们来浏览一下。

Locked Pages

也叫锁定页，在Windows中有一个概念，如果应用程序使用了AWE（Address Windowing Extensions，地址空间扩展）可以避免工作集影响内存使用。在企业版和标准版中是默认启用的。但是Linux中没有AWE这个概念。所以是不能等同使用的。Linux会针对内存消耗来终止进程或者分配页。这个在后续介绍。

即时文件初始化

Instant File Initialization，在Windows平台，如果SQL Server的服务账号具有本机管理器权限，那么会自动启用，如果没有则要修改“执行卷维护计划”的权限给SQL 服务账号，Windows平台是通过调用SetFileValidData()这个API来实现。而Linux平台，首先只有mssql这个账号，但是默认可以执行初始化，Linux通过调用fallocate()这个Linux API来实现，因此不需要额外的配置。

Large Pages

这是Windows平台的概念，当启用跟踪标记834的时候会使用。相对Linux平台，叫做Transparent Huge Pages（THP），影响内存分配，Linux上也存在834这个跟踪标记，但是由于平台的内存调度不同，微软建议仅对特定的高端系统使用。可以参考微软文章：SQL Server 在高性能的工作负载运行时的优化选项

Windows Server Failover Clustering

WSFC，在Windows平台上，借助WSFC，SQL Server可以搭建集群和AlwaysOn技术实现高可用。但是Linux平台不存在WSFC，所以需要使用别的软件，微软建议使用Pacemaker，当然你也可以使用第三方的其他工具实现，只要它们支持。这部分在AlwaysOn章节独立介绍。有兴趣的读者可以先看一下官方文档：故障转移群集实例-Linux 上的 SQL Server