【SQL SERVER】常见问题

【账户】

偷懒默认安装了全部默认功能到虚拟服务器上，所以并没有设置sa账户的过程，自然只能从windows身份验证进入数据库。于是还得自己来为sa账户添加登陆权限。

步骤如下：

1. windows身份验证登入数据库，展开实例-》 安全性，找到登录名，展开后看到实际上默认已经添加了sa账户，但是密码是默认的

2. 双击sa账户，进入设置，首先修改sa的密码

3. 取消“强制实施密码策略”

4. 选择页选中状态页面， 确保设置 “是否允许连接到数据库引擎”和“登陆”分别选择为 “授予” 和 “已启用”

5.上述完成后，务必记得在当前的数据库实例上右键-》属性，修改 “安全性”页中的 “服务器身份验证”为 SQL Server和Windows身份验证模式。

6. 重启数据库实例。

若忘记做第五步则使用sa登陆时报 18456错误。

【运维 17.12.12】

昨天遇到一个故障。用户方由于断电导致集群重启。正常情况下，按我们做好的配置，重启后数据库会自己恢复包括Agent的服务。但是用户打电话告知，数据查不到，登陆不了。问了下情况后，尝试在远端登陆数据库，能成。心里松口气觉得应该没什么大问题。 但是数据库的状态挂在 未同步\正在恢复 上。因为初步推测和断电有关系，用户也说他们启动时顺序有错，判断可能是B结点没有成功启动，造成这个状态。 使用ALTER 命令希望将数据库置为应急，再进一步处理。结果发现执行失败，提示数据库正在使用中。 那么再推测，应当是什么情况阻碍了数据库的同步。

Always On 进行同步的过程是这样：

步骤1：主副本记录发生变化的数据；

步骤2：将记录传输到各个辅助副本；

步骤3:把数据变化操作在辅助副本上执行一遍。

对于一个内网集群而言，传输故障是最容易排除的。只要没有出现诸如故障转移所依赖的域服务失败（最常见的是域账户无法登陆）、故障转移集群被修改【比如IP】、域内的服务器不可达、故障转移集群的共享存储不可达等情况，传输的问题就可以基本排除掉。

那么剩余的问题就是，主副本是否能够记录？辅助副本是否能够执行？

这个问题基本可以当作单个数据库的运维来考虑了。因为1、3步骤不能执行，就和一个普通单节点的数据库不能执行操作一样。而且大多数情况下，产生问题的原因是日志文件。

大家都知道对于需要长期运行的数据库而言，定期的日志截断和备份是必要的。因为这个操作会对日志进行压缩，避免产生日志写满硬盘导致数据库失败的情况。那么如果过期的备份没有及时清理掉，同样会写满硬盘。大多数情况下，在硬盘已满时本次的备份并没完成，于是造成数据库的不可用状态。 因此，暂停所有向数据库的写操作，停止数据库服务并检查存放备份日志的磁盘，便能找到问题。 很走运，这次只是遇到这样的小问题。但如果问题不在这，且ALTER失败，那么可能遇到了很严重的故障。此时再对数据库进行文件转移。

千万注意，对于集群数据库而言，不要轻易进行离线操作。

此外，还应当检查是否有锁出现。有时间还是应该翻一翻master下那些很有用的系统存储过程。

【截断日志并收缩-SQL】

use [DBName]

declare @bakfile nvarchar(100) --@bakfile备份文件名  

set @bakfile='d:\database_bak\log_bak_'+convert(nvarchar(8),getdate(),112)+'.log'

BACKUP LOG [DBName] TO DISK=@bakfile WITH RETAINDAYS=1,COMPRESSION  --dbName为数据库名  

declare @logFile int

set @logFile = (select a.file_id from sys.database_files a where a.name = 'DBName_log' )

dbcc shrinkfile(@logFile,100) --dbName_log为数据库文件逻辑名称，100为希望日志收缩到的MB数  

go

下次更新一个专题，整理一下那些比较有用的脚本。