3.降低本地数据运维成本
因为大部分的温数据和冷数据都保存在云端,我们在本地数据中心,不需要购买大量的存储以保留这些历史数据。 4.保证数据安全
本地SQL Server支持的安全特性,比如Row Level Security (RLS)和其他安全安全特性,在云端Stretch Database也同时支持。 在以下场景中,我们需要使用Azure Stretch Database:
(1)需要对历史数据保存很长一段时间
(2)有时需要对历史数据进行查询
(3)前端应用需要访问这些历史数据,且前端应用不会进行重构
(4)减少购买存储的费用 哪些数据库支持Azure Stretch Database? 我们建议用户使用SQL Server 2016数据库,来启动Stretch功能。
另外,我们建议下载SQL Server 2016 Upgrade Advisor,来定义哪些数据表可以迁移到Stretch Database。 Stretch Database限制: https://azure.microsoft.com/en-us/documentation/articles/sql-server-stretch-database-limitations/ 约束:
需要迁移的数据,如果包含Unique约束和Primary Key约束,则这些约束不会被启用
Uniqueness is not enforced for UNIQUE constraints and PRIMARY KEY constraints in the Azure table that contains the migrated data. DML操作:
1.可以迁移到云端(但未迁移)的SQL数据(表Table或者试图View),或者已经迁移到Stretch Database云端的SQL数据,无法执行UPDATE和DELETE操作。
2.不可以在linked server上对已经stretch的表执行插入操作
You can't INSERT rows into a Stretch-enabled table on a linked server. 索引:
1.无法对已经Stretch的表创建索引
2.对本地SQL Server的过滤操作,不会传播到Azure SQL Stretch Table
Filters on SQL Server indexes are not propagated to the remote table 对Table的限制:
1.Table不能超过1023列或多于998个索引
2.不能包含FileStream数据
3.不支持Change Tracking或者Change Data Capture
4.内存优化的表 不支持的数据类型:
1.text, ntext and image
2.timestamp
3.sql_variant
4.XML
5.CLR data types including geometry, geography, hierarchyid, and CLR user-defined types 不支持的列的类型:
1.Default constraints and check constraints
2.外键表所在的主键表
Foreign key constraints that reference the table. In a parent-child relationship (for example, Order and Order_Detail), you can enable Stretch for the child table (Order_Detail) but not for the parent table (Order). 不支持的索引: