SQLSERVER DBA那些事

作者:课课家教育更新于： 2017-05-15 17:28:05

　　我们平时都会犯错误，系统、软件也不例外，就拿SQLSERVERDBA来讲，它也有容易犯的十个错误，除了排名前十的错误之外，其他排名靠前的错误有：

　　抛开SQLServer方面的错误,这些错误主要体现在开发或者是设计的时候:

　　1、不合理的规范和不合理的数据库设计

　　2、没有设计好可伸缩性的需求

　　3、没有数据库性能基线或基准

　　4、索引的问题

　　5、对语句调优不够重视

　　一、错误倒数第十位(磁盘-只要磁盘空间充足就不理会磁盘IO了)

　　经常只考虑磁盘子系统的磁盘空间，不理会IO负载

　　没有足够的专业知识，有可能会出现以下问题：

　　选择了不恰当的容错机制

　　IO性能不足：

　　OLTP系统需要较高的TPS

　　OLAP需要较高的传输速度

　　选择了较差的RAID类型、控制器、通道

　　没有足够的磁盘主轴

　　SSD固态硬盘可以改变这个IO游戏的规则

　　二、错误倒数第九位(对业务规则不理解)

　　作为一位ITPRO，你应该知道SQLServer内部是如何工作的

　　什么是checkpoint？什么是Lazywriter？

　　TempDB的使用方式是怎样的？plancache里面有什么？

　　你要知道DBA是企业资产数据的保护者

　　业务和IT之间的联系,你应该知道如何以及在何种方式使用您的服务器

　　当程序down掉的时候谁会在意，每分钟的停机时间公司需要损失多少钱?

　　商业周期是什么?

　　什么时候是最好的宕机?

　　什么样的的基线、基准是正常的？

　　三、错误倒数第八位(没有一套自己的故障排除方法)

　　危急时,DBA需要一个强大的、一步一步的方法进行根源分析。

　　如果没有，你将会：

　　1、错过了数据库的错误和问题

　　2、由于错误引起的数据丢失或者灾难性的问题

　　3、很差的响应时间或者会违反SLA服务级别协议

　　4、失去信誉

　　四、错误倒数第七位(基本上都使用默认值)

　　使用默认值安装SQLServer安装的目的是尽快让服务器启动并运行

　　但是这样会造成运行时得不到最优，例如如下设置：

　　数据库自动增长、自动收缩

　　数据库自动增长的大小

　　默认文件组

　　一些小问题也会成为大问题

　　1、并行度

　　2、填充因子

　　其他一些服务器和数据库的设置选项

　　错误倒数第六位(在事后才想起数据库的安全性)

　　现在互联网上面的SQL注入漏洞成为第一位

　　值得注意的是,十年前很多关于防SQL注入的方法，直到今天我们依然继续在使用

　　提前计划好使问题最小化：

　　确保您的服务器上运行的应用程序只有最小的权限，并且这个权限能够保证你的程序能正常运行

　　你的服务器暴露面有多少？暴露越多受攻击面就越广

　　谁有权访问你的服务器？

　　当出问题的时候你如何找出谁开了一些不恰当的权限？

　　五、错误倒数第五位(没有充分使用自动化)

　　自动化能减轻DBA的很多工作，讽刺的是,一开始DBA就需要将大量的工作进行自动化

　　没有自动化，DBA必须面对下面问题：

　　如果全靠人去操作有可能容易出错和遗漏

　　当服务器的数量增加的时候你的工作将会加倍

　　使用自动化的例子：

　　自动报错通知

　　维护计划作业

　　基本都是脚本，而不需要使用GUI

　　六、错误倒数第四位(在工作上使用了不合适的功能或技术)

　　DBA是公司里IT程序的“性能工程师”

　　他的工作是对于每个业务需求使用最合适的功能

　　否则就会：

　　使应用程序变复杂

　　过度的资源消耗

　　有一条定理：没有IT的项目，只有利用IT解决商业项目

　　七、错误倒数第三位(对管理的变更很冷漠)

　　变更管理是很重要的！没有管理变更，dba将面临：

　　如果不变，那么他们所做的事情将会更加糟糕

　　改变控制对改变管理

　　合理的管理改变意味着：

　　在规定好的时间限制里面预先规划好时间

　　在生产环境里面，管理改变的好坏会被验证和测试

　　改变是隔离的、原子的、可逆的

　　八、错误倒数第二位(不恰当的维护计划)

　　适当的预防性维护(PM)可以帮助您:

　　在出现问题之前抓住问题

　　能确定优化方向

　　用户在系统上执行资源密集型的操作会减少

　　预防性维护在SQLSERVER里应该包括

　　数据库一致性检查和DBCCCHECKIDENT

　　备份和还原数据库的时候使用校验选项

　　索引填充因子、碎片整理

　　索引统计信息

　　不要依赖数据库维护计划向导！！

　　不用重复做轮子，有很多维护计划已经有人帮我们写好了

　　九、错误倒数第一位(备份和还原)

　　DBA不会经常验证备份的可用性

　　这会带来一些问题：

　　您对客户的SLA不能保证，还有RTO和RPO不能保证

　　没人能确保备份可用

　　既然SQLSERVERDBA会有犯错误的时候，那么我们也有5个让DBA爱上你的SQL技巧！

　　一、不要在索引列上调用Function

　　这样做将会阻止数据库使用这个索引，这个问题甚至可以影响这个分区表，因为这样做的话将不会从指定的分区中读取数据，而是扫描整一个表空间。对于大数据量的数据表，这将是性能上的一场大灾难。

　　不要这样做：

　　应该这样做：

　　二、使用Analyze对复杂SQL的优化

　　如果你不这样做，将意味着：你拒绝使用数据库的查询优化器，也失去了使用优化连接的机会。假设你创建了一张拥有100万条记录的临时表，如果不对其进行分析，那么优化器将无法从现有的线索中获取表中真正的内容，于是它只能决定使用嵌套循环连接来一行行地扫描数据表，如果数据量不大，可能我们感觉不到性能的损失，但是随着数据集的增长，你的数据库性能会越来越差。

　　建议这样做：

　　三、将复杂的SQL分成几步执行

　　把SQL想象成披萨，我想你应该不会一下子将整个披萨吞到嘴里嚼烂它吧。

　　对于创建一个复杂的SQL查询，我们最好将其分成3-4个步骤，SQL越简单，优化器的效果就越好，另外，对每一张数据表中的数据也越容易调试。

　　四、只有在必要的时候才使用Distinct

　　这是一个非常好的经验法则，Distinct经常被用在返回2条或2条以上重复记录的SQL查询中，使用Distinct，将会过滤掉重复的数据记录。但是使用Distinct的目的一定要明确，当你确定返回的记录一定是唯一的时候才能使用，比如用户id。滥用Distinct将会出现不可预知的错误，比如多表连接查询的情况。

　　五、合理创建索引

　　最后一点就是合理创建表索引，简单来说，假如有一张10万条记录的数据表，你可能经常会查询这样的信息：“我的某个客户信息在这张表中吗？”。如果使用了索引，那么检索这条客户信息将非常迅速，否则数据库优化器将会选择全表扫描，这在大数据量的情况下简直就是噩梦。

　　小编结语：

　　更多内容尽在课课家教育！