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)的方式来选择其他数据库。不能在界面中选择。如图直接登录的话,会登陆到账号配置的默认数据库。
    Azure SQL DB/DW 系列(1)——首次使用感受_第1张图片
  2. 或者在连接的过程选择目标数据库:
    Azure SQL DB/DW 系列(1)——首次使用感受_第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)——入门级监控性能的工具

你可能感兴趣的:(Azure,SQL,DB,Azure)