Azure SQL DB/DW 系列（1）——首次使用感受

本文属于Azure SQL DB/DW系列

1. 云平台的产品变化非常快，所以本系列所有内容都不保证在半年或者一年之后还能适用，最新的内容还需查看官方文档。我也会尽量给出官方链接。
2. 由于不同的云供应商有自己的封装，加上本人目前公司的项目使用国际版的微软云Azure，所以我的环境只集中在国际版的Azure平台。
3. 本文属于需要不断完善的文章，一旦我在工作和学习中有新的内容，会同步更新到本文种。

1. Azure SQL DB/DW 系列（1）——首次使用感受
2. Azure SQL DB/DW 系列（2）——入门级监控性能的工具
3. Azure SQL DB/DW 系列（3）——Query Store简介
4. Azure SQL DB/DW 系列（4）——Query Store案例（1）——缺失索引
5. Azure SQL DB/DW 系列（5）——Query Store案例（2）——计划回归
6. Azure SQL DB/DW 系列（6）——Query Store案例（3）——查看等待信息
7. Azure SQL DB/DW 系列（7）——Query Store案例（4）——查找参数化问题
8. Azure SQL DB/DW 系列（8）——重新认识Query Store（1）——简介
9. Azure SQL DB/DW 系列（9）——重新认识Query Store（2）——工作原理
10. Azure SQL DB/DW 系列（10）——重新认识Query Store（3）——配置查询存储
11. Azure SQL DB/DW 系列（11）——重新认识Query Store（4）——Query Store维护
12. Azure SQL DB/DW 系列（12）——使用Query Store（1）——报表介绍（1）
13. Azure SQL DB/DW 系列（13）——使用Query Store（2）——报表介绍（2）
14. Azure SQL DB/DW 系列（14）——使用Query Store（3）——常用场景

前言

  云计算已经不再是什么新鲜事，作为IT人员更加如此。目前我负责Azure 平台的SQL DB和SQL DW（现在叫Azure Synapse Analytics，不过名字太不好记，我们还是习惯用DW来指代）。由于工作需要，我会整理各种产品的费用，配置和适用场景等资料。也会根据项目要求进行一些平台迁移，比如最近要做SQL DB迁移到SQL DW的工作。
  本系列第一篇，我打算介绍一下工作中困扰我最多的问题——性能问题。准确来说是性能监控。之所以那么困难，是因为SQL DB和SQL DW是PaaS平台产品，换句话来说，它们有很多的限制，特别是对常规DBA工作而言。我可以在传统环境下使用sp_whoisactive来监控和解决绝大部分性能问题。但是这个极其有用的sp并不能在部署到SQL DB上，这个接下来会说。

PaaS平台和传统平台的不同

  在开始之前，有必要说一下PaaS和传统平台(也就是在操作系统上面安装SQL Server，不管这台服务器是实体机，还是自建机房的虚拟机，或者在云平台上建的虚拟机（IaaS），由于它们几乎都是一样的，所以归成一类)的一些差异，我不打算说全部，毕竟我没有“遇到过”全部情景。我只想介绍我在实际项目中遇到的问题，这样比官方文档更有血有肉，而且我在以后找问题甚至传递经验的时候也更有说服力。

连接方式不同

  假设现在你已经有了一个通过Azure的门户（portal）或者Powershell创建的各种前置资源，由于我不是公司云平台的超级管理员，所以我没办法演示这部分。当环境已经交付并提供连接信息之后，你就可以用SSMS或者Azure Data Studio来连接PaaS的数据库了。但是这个时候你会发现几个与常规连接不同的地方：

1. 如果一个实例（本地版）或者叫服务器（PaaS）下有多个数据库，云版本在连接时就需要指定，否则会到master或者所用账号默认指定的数据库中，非master库一旦连接成功之后，你需要使用新建窗口（ctrl+N)的方式来选择其他数据库。不能在界面中选择。如图直接登录的话，会登陆到账号配置的默认数据库。
   
2. 或者在连接的过程选择目标数据库：
   
3. 在连接的过程中，还有一个比较烦人的问题就是公有云的外围设置，特别是防火墙和权限设置，这个问题经常影响产品测试，进行很多尝试之后才发现网络不通或者账号不具有足够的权限。

不支持的T-SQL命令

  下面说一下一些在本人工作过程中发现的不支持的功能，具体内容还是以官网为准：Azure SQL 数据库不支持的 Transact-SQL 语法

• 不能用use：首当其冲的是“Use” 数据库名，这个也是sp_whoisactive不能使用的其中一个原因。
• 某些sp_help命令不能用，比如sp_helpuser
• Azure SQL DW不支持sp_who/sp_who2和sys.sysprocesses 这类查看会话状态的工具。

不能使用的功能

1. 在SSMS中你看不到msdb
2. PaaS版本的SQL Server有单库4TB的大小限制。
3. 不支持备份还原操作，但是在门户上可以操作。并且默认保留7天备份，可以选择35天，最高10年（LTR，long-term retention)。
4. 除了托管实例（managed instance）之外，不支持CDC，这点很要命，很多DW/OLAP项目都需要CDC来跟踪数据变更并进行数据同步。
5. 不能操作几乎所有常规的文件级别功能，这部分由微软来管理。
6. 账号的配置有所不同，可以看我另外一篇：SQL Azure 工作积累（1）——添加用户到Azure SQL DB
7. SQL Agent需要用其他Azure的服务来搭配。
8. 不能在SSMS中CREATE DATABASE，需要在Azure的门户上执行。
9. 待补充。

PaaS的优势

  但是无可否则，PaaS的DB有它自己的优势，比如可以很容易地扩展资源，而不用像传统模式那样走流程等到货然后上架，有时还会出现机架不够空间的情况。
  还有一点，所有SQL Server上的新功能都首先会在PaaS平台上出现，也就是说PaaS的功能是最新的，除了那些天生就是为了非云环境开发的功能。所以你可以在Azure SQL DB上尝试到最新的功能。

上云的挑战

  在使用过程中，我感觉到几个挑战，首先就是你需要学习大量的云及特定云的服务/产品，比如SQL Server的SQL Agent，大数据相关的配套，还有网络配置，网络安全等内容。毕竟很多在本地环境下可以一起使用的功能被拆成很多个服务/产品，如何使用及打通链路都是额外的工作量。
  其次就是由于某些功能的不支持，不是每个系统都能简单地迁移到云上。需要大量的工作量。
  自从出现了云平台之后，我们会经常听说某某新功能，觉得可以试用，结果发现只能适用于云或者本地，所以在接下来的日子里，我们都要首先了解某个功能的适用环境。这也增大了我们的学习成本。
  沟通成本，现在很多术语已经有了专用的指代，而不是当初的简单SQL Server就包含了数据库的全部。比如现在SQL Server实际上就是只非云版本， Azure SQL DB或者SQL DB就是指微软云上的SQL Server PaaS版本，Azure Synapse Analytics (SQL DW) 指的是微软云上的数据仓库PaaS版本。SQL Server on Linux指的是Linux平台上的SQL Server本地版。后续我也会使用这种叫法，这种叫法得到了微软的认可（就是在与微软技术支持沟通过程中的叫法）。

下一文：Azure SQL DB/DW 系列（2）——入门级监控性能的工具