novedades sql server 2014
Post on 26-Jan-2015
108 Views
Preview:
DESCRIPTION
TRANSCRIPT
Microsoft SQL Server 2014NOVEDADES
Por Xavier SaladiéJulio 2014
Microsoft SQL Server 2014What’s new?
• In-Memory OLTP• New Cardinality Estimator• Security Enhancements• AlwaysOn Enhancements• Resource Governor I/O• Working with Azure
SQL Server 2014In-Memory OLTP
4
SQL Server engine
In-memory OLTP
• Low latency
• Up to 30 times the improvement in performance
• 2 to 5 times the improvement in scalability
• Takes advantage of investments in Microsoft SQL Server
New high-performance, memory-optimized online transaction processing (OLTP) engine integrated into SQL Server and architected for modern hardware trends
• Integrated into SQL Server relational database• Full ACID support• Memory-optimized• Non blocking multi-version optimistic concurrency
control (no locks or latches)• T-SQL compiled to native code
Memory-optimized table
file group
In-Memory OLTP engine: Memory-optimized tables & indexes
Native compiled SPs & schema
In-Memory OLTP compiler
TDS handler and session management
Transaction log Data file group
Buffer pool for tables & indexesLock Manager
Proc/plan cache for ad-hoc, T-SQL; interpreter, plans, etc.
Parser, catalog, optimizer
5
Suitable application characteristics
• Application is suited for in-memory processing‐ All performance critical data already fits in memory
‐ Transaction locking or physical latching causing stalls and blocking
• Application is “OLTP-Like”‐ Relatively short-lived transactions
‐ High degree of concurrent transactions from many connections
‐ Examples: Stock trading, travel reservations, order processing
• Application porting simplified if‐ Stored procedures used
‐ Performance problems isolated to subset of tables and SPs
SQL Server integration
• Same manageability, administration, and development experience
• Integrated queries and transactions
• Integrated HA and backup/restore
Main-memory optimized
• Optimized for in-memory data
• Indexes (hash and range) exist only in memory
• No buffer pool• Stream-based
storage for durability
High concurrency
• Multiversion optimistic concurrency control with full ACID support
• Core engine uses lock-free algorithms
• No lock manager, latches, or spinlocks
T-SQL compiled to machine code
• T-SQL compiled to machine code via C code generator and Visual C compiler
• Invoking a procedure is just a DLL entry-point
• Aggressive optimizations at compile time
Steadily declining memory price, NVRAM
Many-core processors Stalling CPU clock rate TCO
Hardware trends Business
Hybrid engine and integrated experience
High-performance data operations
Frictionless scale-up
Efficient, business-logic processingB
enefits
In-M
em
ory
OLT
P T
ech
Pill
ars
Dri
vers
In-memory OLTP architecture
Main-memory optimized
• Optimized for in-memory data
• Indexes (hash and ordered) exist only in memory
• No buffer pool• Stream-based
storage for durability
Steadily declining memory price, NVRAM
Hardware trends
Design considerations for memory-optimized tables
7
Table constructsFixed schema; no ALTER TABLE; must drop/recreate/reload
No LOB data types; row size limited to 8,060
No constraints support (primary key only)
No identity or calculated columns, or CLR
Data and table size considerationsSize of tables = (row size * # of rows)
Size of hash index = (bucket_count * 8 bytes)
Max size SCHEMA_AND_DATA = 512 GB
IO for durability SCHEMA_ONLY vs. SCHEMA_AND_DATA
Memory-optimized filegroup
Data and delta files
Transaction log
Database recovery
High performance data operations
Benefits
In-M
em
ory
OLT
P
Tech
Pill
ars
Dri
vers
Create Table DDL
CREATE TABLE [Customer]( [CustomerID] INT NOT NULL
PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000), [Name] NVARCHAR(250) NOT NULL
INDEX [IName] HASH WITH (BUCKET_COUNT = 1000000), [CustomerSince] DATETIME NULL)WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
This table is memory optimized
This table is durable
Secondary indexes are specified inline
Hash index
Create Procedure DDL
CREATE PROCEDURE [dbo].[InsertOrder] @id INT, @date DATETIME WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNERAS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = 'us_english')
-- insert T-SQL hereEND
This proc is natively compiled
Native procs must be schema-bound
Atomic blocks • Create a transaction if
there is none• Otherwise, create a
savepoint
Execution context is required
Session settings are fixed at create time
10
High concurrency
• Multiversion optimistic concurrency control with full ACID support
• Core engine uses lock-free algorithms
• No lock manager, latches, or spinlocksMany-core
processors
Hardware trends
High-concurrency design considerations
Impact of no locks or latchesWrite-write conflict: design application for condition with try.catch
Applications dependent on locking; may not be a good candidate
Multiple versions of recordsIncreases the memory needed by memory-optimized tables
Garbage Collection used to reclaim old versions
Transaction scopeSupport for Isolation Levels: Snapshot, Repeatable Read, Serializable
Commit time validation; again must retry logic to deal with failure
Frictionless scale-up
Benefits
In-M
em
ory
OLT
P
Tech
Pill
ars
Dri
vers
11
Example: Write conflict
Time Transaction T1 (SNAPSHOT) Transaction T2 (SNAPSHOT)
1 BEGIN
2 BEGIN
3 UPDATE t SET c1=‘bla’ WHERE c2=123
4 UPDATE t SET c1=‘bla’ WHERE c2=123 (write conflict)
First writer wins
12
Guidelines for usage
1. Declare isolation level – no locking hints
2. Use retry logic to handle conflicts and validation failures
3. Avoid using long-running transactions
13
T-SQL compiled to machine code
• T-SQL compiled to machine code via C code generator and Visual C compiler
• Invoking a procedure is just a DLL entry-point
• Aggressive optimizations at compile-time
Stalling CPU clock rate
Hardware trends
Design considerations for native compiled stored procedures
Efficient business-logic processingB
enefits
In-M
em
ory
OLT
P T
ech
Pill
ars
Dri
vers
Native compiled stored procedures
Non-native compilation
Performance High. Significantly less instructions to go through
No different than T-SQL calls in SQL Server today
Migration strategy Application changes; development overhead
Easier app migration as can still access memory-optimized tables
Access to objects Can only interact with memory-optimized tables
All objects; access for transactions across memory optimized and B-tree tables
Support for T-SQL constructs
Limited T-SQL surface area (limit on memory-optimized interaction)
Optimization, stats, and query plan
Statistics utilized at CREATE -> Compile time
Statistics updates can be used to modify plan at runtime
Flexibility Limited (no ALTER procedure, compile-time isolation level)
Ad-hoc query patterns
14
Performance gains
In-Memory
OLTP Compiler In-Memory
OLTP Component
Memory-optimized Table Filegroup
Data Filegroup
SQL Server.exe
In-Memory OLTP Engine for Memory_optimized
Tables & Indexes
TDS Handler and Session Management
Natively Compiled SPs and Schema
Buffer Pool for Tables & Indexes
Proc/Plan cache for ad-hoc T-SQL and SPs
Client App
Transaction Log
Interpreter for TSQL, query plans, expressions
Query Interop
Access Methods
Parser, Catalog,
Algebrizer, Optimizer
10-30x more efficient
Reduced log bandwidth &
contention. Log latency remains
Checkpoints are background
sequential IO
No improvements in communication
stack, parameter passing, result set
generation
Key
Existing SQL
Component
Generated .dll
15
In-memory data structures
Rows• New row format
Structure of the row is optimized for memory residency and access
• One copy of row
Indexes point to rows, they do not duplicate them
Indexes• Hash index for point lookups• Memory-optimized nonclustered index for range and
ordered scans• Do not exist on disk – recreated during recovery
Memory-optimized table: Row format
Key Points• Begin/End timestamp determines row’s validity• No data or index page; just rows• Row size limited to 8060 bytes to allow data to be moved to disk-based table• Not every SQL table schema is supported
Row header Payload (table columns)
Begin Ts End Ts StmtIdIdxLinkCou
nt
8 bytes 8 bytes 4 bytes 2 bytes
8 bytes * (IdxLinkCount – 1)
Key lookup: B-tree vs. memory-optimized table
Matching index record
Hash index on Name
R1 R2
R3
Non-clustered index
OLTP Rocket Science
• No DML triggers • No FOREIGN KEY or CHECK constraints • No IDENTITY columns• 8060 byte hard limit for row length • No UNIQUE indexes other than for the PRIMARY KEY • A maximum of 8 indexes, including the index supporting the
PRIMARY KEY • No schema changes are allowed once a table is created
(drop/recreate) • Indexes are always and ONLY created at as part of the table
creation
In-Memory OLTP Limitations
Indexes Comparison for different kinds of operations
Operation Memory hashMemory nonclustered Disk
Index Scan, retrieve all table rows. Yes Yes Yes
Index seek (=).Yes (Full key required.) Yes 1 Yes
Index seek (>, <, <=, >=, BETWEEN). No (index scan) Yes 1 Yes
Retrieve rows in a sort-order matching the index definition. No Yes Yes
Retrieve rows in a sort-order matching the reverse of the index definition.
No No Yes
21
Memory management
Data resides in memory at all times• Must configure SQL server with sufficient memory to
store memory-optimized tables• Failure to allocate memory will fail transactional
workload at run-time• Integrated with SQL Server memory manager and
reacts to memory pressure where possible
Integration with Resource Governor• “Bind” a database to a resource pool• Mem-opt tables in a database cannot exceed the
limit of the resource pool• Hard limit (80% of phys. memory) to ensure system
remains stable under memory pressure
Garbage collection
22
Stale Row Versions• Updates, deletes, and aborted insert operations
create row versions that (eventually) are no longer visible to any transaction
• Slow down scans of index structures• Create unused memory that needs to be
reclaimed (i.e. Garbage Collected)
Garbage Collection (GC)• Analogous to version store cleanup task for
disk-based tables to support Read Committed Snapshot (RCSI)
• System maintains ‘oldest active transaction’ hint
GC Design• Non-blocking, Cooperative, Efficient,
Responsive, Scalable• A dedicated system thread for GC • Active transactions work cooperatively and pick
up parts of GC work
Cooperative garbage collection
Key Points• Scanners can remove expired rows
when found• Offloads work from GC thread• Ensures that frequently visited areas of
the index are cleaned regularly
• A row needs to be removed from all indexes before memory can be freed
• Garbage collection is most efficient if all indexes are frequently accessed
100 200 1 John Smith Kirkland
200 ∞ 1 John Smith Redmond
50 100 1 Jim Spring Kirkland
300 ∞ 1 Ken Stone Boston
TX4: Begin = 210Oldest Active Hint = 175Index
24
Durability
Memory-optimized tables can be durable or non-durable• Default is ‘durable’• Non-durable tables are useful for transient data
Durable tables are persisted in a single memory-optimized file group
Storage used for memory-optimized has a different access pattern than for disk tables
File group can have multiple containers (volumes)Additional containers aid in parallel recovery; recovery happens at the speed of IO
25
On-disk storage
Filestream is the underlying storage mechanismChecksums and single-bit correcting ECC on files
Data files• ~128MB in size, write 256KB chunks at a time• Stores only the inserted rows (i.e. table content)• Chronologically organized streams of row versions
Delta files• File size is not constant, write 4KB chunks at a time.• Stores IDs of deleted rows
26
Logging for memory-optimized tables
Uses SQL transaction log to store content
Each log record contains a log record header followed by opaque memory optimized-specific log content
All logging for memory-optimized tables is logical
• No log records for physical structure modifications.
• No index-specific / index-maintenance log records.
• No UNDO information is logged
Recovery Models
All three recovery models are supported
27
Backup for memory-optimized tables
Integrated with SQL Database Backup
• Memory-Optimized file group is backed up as part SQL Server database backup
• Existing backup scripts work with minimal or no changes
• Transaction log backup includes memory-optimized log records
Not supported
Differential backup
28
Recovery for memory-optimized tables
Analysis Phase
Finds the last completed checkpoint
Data Load
• Load from set of data/delta files from the last completed checkpoint
• Parallel Load by reading data/delta files using 1 thread / file
Redo phase to apply tail of the log
• Apply the transaction log from last checkpoint
• Concurrent with REDO on disk-based tables
No UNDO phase for memory-optimized tables
Only committed transactions are logged
Myth #1
Reality
Project “Hekaton” was started around 4 years ago in response to business and hardware trends
SQL Server In-Memory OLTP is a recent response to competitors’ offerings
Myth #2
Reality
In-memory OLTP is completely new design to optimize for efficient In-Memory data operations.
There are no pages or buffer pool for memory-optimized tables.
In-Memory OLTP is like DBCC PINTABLE
Myth #3
Reality
In-Memory OLTP is a feature fully integrated into SQL Server 2014
In-Memory Databases are new separate products
Myth #4
Reality
There are at least some changes, at minimum changing some of the schema
You can use In-Memory OLTP in an existing SQL Server app with NO changes whatsoever
Myth #5
Reality
In-Memory OLTP is fully durable, and includes several HA features, including AlwaysOn
Data is persisted on disk, and will survive server crash
Since tables are in memory, the data is not Durable or Highly Available – I will lose it after server crash
Demo
In-Memory Tables Performance
35
In-memory OLTP summary
What’s being delivered
• High-performance, memory-optimized OLTP engine integrated into SQL Server and architected for modern hardware trends
Main benefits• Optimized for in-memory data up to 20–30 times
throughput‐ Indexes (hash and range) exist only in memory; no buffer
pool, B-trees‐ T-SQL compiled to machine code via C code generator and
Visual C compiler‐ Core engine uses lock-free algorithms; no lock manager,
latches, or spinlocks
• Multiversion optimistic concurrency control with full ACID support
• On-ramp existing applications• Integrated experience with same manageability,
administration, and development experience
SQL Server 2014Cardinality Enhancements
Cardinality
37
• Execution Plans uses Cardinality in order to get an estimation of number of rows for each query
• Although the new cardinality still works based on Statistics the algorithm has been dramatically changed
• Databases in native compatibility level (120) works with the new estimator version
• Change that behavior with the OPTION (QUERYTRACEON 9481) to still be executed with the old version (per Query basis)
• Databases in compatibility level 110 could be executed with the new version when using QUERYTRACEON 2312 hint (per Query basis)
Scenarios
38
• New cardinality estimates use an average cardinality for recently added ascending data (ascending key problem) without Statistics Update
‐ Old Version estimates 0 rows
‐ New Version uses average cardinality
• New cardinality estimates assume filtered predicates on the same table have some correlation
‐ Old and New Version depends on the specific sample
• New cardinality estimates assume filtered predicates on different tables are independent
‐ Old and New Version depends on the specific sample
39
• Check the performance of your workloads and do the math
‐ Compatibility Level 110
‐ Compatibility Level 110 and add OPTION (QUERYTRACEON 2312) to some querys
‐ Native Compatibility Level (120)
‐ Native Compatibility Level (120) and add OPTION (QUERYTRACEON 9481) to some querys
Suggestions
Demo
Cardinality
SQL Server 2014Security Enhancements
Separation of duties enhancement
• Four new permissions‐ CONNECT ANY DATABASE (server scope)
‐ IMPERSONATE ANY LOGIN (server scope)
‐ SELECT ALL USER SECURABLES (server scope)
‐ ALTER ANY DATABASE EVEN SESSION (database scope)
• Main benefit‐ Greater role separation to restrict multiple DBA roles
‐ Ability to create new roles for database administrators who are not sysadmin (super user)
‐ Ability to create new roles for users or apps with specific purposes
Best practices for separation of duties
• Eliminate the use of superusers (SA login, SYSADMIN server role, DBO database user)
• Use permission system rather than superuser
• Use CONTROL SERVER (server level) and CONTROL DATABASE (database level) instead and use DENY for specifics
• Always document the user of ownership chains
Backup encryption
• Increase security of backups stored separate from the instance (another environment such as the Cloud)
• Encryption keys can be stored on-premises while backup files in the cloud
• Support non-encrypted databases (don’t need to turn on Transparent Data Encryption anymore)
• Different policies for databases and their backups
T-SQL BACKUP / RESTORE
BACKUP DATABASE <dbname> TO <device> = <path to device>WITHENCRYPTION( ALGORITHM = <Algorithm_name> , { SERVER CERTIFICATE = <Encryptor_Name> | SERVER ASYMMETRIC KEY = <Encryptor_Name> } );
No changes to RESTORE
T-SQL views
• msdb.dbo.backupset
• msdb.dbo.backupmediaset
backup_set_id name key_algorithm encryptor_thumbprint encryptor_type
3 Full Backup NULL NULL NULL
4 Full Backup aes_256 0x00B1BD62DAA0196 CERTIFICATE
media_set_id is_password_protected is_compressed is_encrypted
3 0 1 0
4 0 1 1
Additional details
• AES 128, AES 192, AES 256, and Triple DES
• Unique backup key is generated for each backup
• Certificate
• Asymmetric key from an EKM provider only
• All operations require certificate or key
• Appended backup is not supported
• Compression has no effect on pre-encrypted databases
SQL Server 2014AlwaysOn Enhancements
AlwaysOn in SQL Server 2014• What’s being delivered
• Increase number of secondaries from four to eight• Increase availability of readable secondaries• Support for Windows Server 2012 CSV• Enhanced diagnostics
• Main benefits• Further scale out read workloads across (possibly geo-distributed) replicas • Use readable secondaries despite network failures (important in geo-distributed
environments)• Improve SAN storage utilization
• Avoid drive letter limitation (max 24 drives) via CSV paths• Increase resiliency of storage failover
• Ease troubleshooting
Description
• Increase number of secondaries (4–8)• Max number of sync secondaries is still two
Increase number of Availability Group secondaries
Reason
• Customers want to use readable secondaries• One technology to configure and manage• Many times faster than replication
• Customers are asking for more database replicas (4–8)• To reduce query latency (large-scale
environments)• To scale out read workloads
Description
Allow FCI customers to configure CSV paths for system and user databases
Support for Windows Server Cluster Shared Volumes
Reason
• Avoid drive letter limitation on SAN (max 24 drives)• Improves SAN storage utilization and management• Increased resiliency of storage failover (abstraction of temporary
disk-level failures)• Migration of SQL Server customers using PolyServe (to be
discontinued in 2013)
Description
Allow FCI customers to configure CSV paths for system and user databases
Support for Windows Server Cluster Shared Volumes
Reason
• Avoid drive letter limitation on SAN (max 24 drives)• Improves SAN storage utilization and management• Increased resiliency of storage failover (abstraction of temporary
disk-level failures)• Migration of SQL Server customers using PolyServe (to be
discontinued in 2013)
SQL Server 2014Resource Governor with IO
Resource Governor goals
• Ability to differentiate workloads
• Ability to monitor resource usage per group
• Limit controls to enable throttled execution or prevent/minimize probability of “run-aways”
• Prioritize workloads
• Provide predictable execution of workloads
• Specify resource boundaries between workloads
Resource Governor components
Complete resource governance
• What’s being delivered‐ Add max/min IOPS per volume to Resource Governor pools
‐ Add DMVs and perfcounters for IO statistics per pool per volume
‐ Update SSMS Intellisense for new T-SQL
‐ Update SMO and DOM for new T-SQL and objects
• Main benefits‐ Better isolation (CPU, memory, and IO) for multitenant
workloads
‐ Guarantee performance in private cloud and hosters scenario
Resource pools
• Represents physical resources of server
• Can have one or more workloads assigned to pool
• Pool divided into shared and non-shared
• Pools control min/max for CPU/memory and now IOPS
CREATE RESOURCE POOL pool_name[ WITH ( [ MIN_CPU_PERCENT = value ] [ [ , ] MAX_CPU_PERCENT = value ] [ [ , ] CAP_CPU_PERCENT = value ] [ [ , ] AFFINITY {SCHEDULER = AUTO | (Scheduler_range_spec) | NUMANODE = (NUMA_node_range_spec)} ] [ [ , ] MIN_MEMORY_PERCENT = value ] [ [ , ] MAX_MEMORY_PERCENT = value ] [ [ , ] MIN_IOPS_PER_VOLUME = value ] [ [ , ] MAX_IOPS_PER_VOLUME = value ])]
Resource pools
• Minimums across all resource pools can not exceed 100 percent
• Non-shared portion provides minimums
• Shared portion provides maximums
• Pools can define min/max for CPU/Memory/IOPS‐ Mins defined non-shared
‐ Max defined shared
Steps to implement Resource Governor
• Create workload groups
• Create function to classify requests into workload group
• Register the classification function in the previous step with the Resource Governor
• Enable Resource Governor
• Monitor resource consumption for each workload group
• Use monitor to establish pools
• Assign workload group to pool
Resource Governor scenarios
• Scenario 1: I just got a new version of SQL Server and would like to make use of resource governor. How can I use it in my environment?
• Scenario 2 (based on Scenario 1): Based on monitoring results I would like to see an event any time a query in the ad-hoc group (groupAdhoc) runs longer than 30 seconds.
• Scenario 3 (based on Scenario 2): I want to further restrict the ad-hoc group so it does not exceed 50 percent of CPU usage when all requests are cumulated.
Monitoring Resource Governor
• System views‐ sys.resource_governor_resource_pools‐ sys.resource_governor_configuration
• DMVs‐ sys.dm_resource_governor_resource_pools ‐ sys.dm_resource_governor_resource_pool_volumes‐ sys.dm_resource_governor_configuration
• New performance counters‐ SQL Server:Resource Pool Stats ‐ SQL Server:Workload group
• XEvents‐ file_read_enqueued‐ file_write_enqueued
SQL Server 2014Backup to Cloud
Backup to Windows Azure
What’s being delivered• SQL Server supports backups to and restores from the Windows Azure Blob
storage service (UI, T-SQL, PowerShell commandlets)
Main benefit: Take advantage of Windows Azure Blob storage• Flexible, reliable (3-copies geo-DR), and limitless off-site storage• No need of backup media management• No overhead of hardware management
CREATE CREDENTIAL mystoragecredWITH IDENTITY = ‘mystorage',SECRET = ‘<your storage access key> BACKUP DATABASE mydb TO URL ='https://mystorage.blob.core.windows.net/backup-container/mydb-20130411.bak'WITH CREDENTIAL = ‘mystoragecred', FORMAT, COMPRESSION, STATS = 5,MEDIANAME = ‘mydb backup 20130411', MEDIADESCRIPTION = 'Backup of mydb'
Backup to Windows Azure
Windows Azure storage
WA
Win
dow
s A
zure
Blo
bs• On-site/off-site storage
costs• Device management
costs
Box
• XDrives limited to 1 terabyte
• Max 16 drives• Manage drives and policy
• Near “bottomless” storage
• Off-site, geo-redundant• No provisioning• No device management• Media safety (decay-
free)• Remote accessibility
On-premises server
Windows Azure VM
Backup to Windows Azure
• Simple configuration UI• Easy creation of Azure credential• No overhead
Restore GUI Backup GUI
Backup to Windows Azure Tool
• What is it?‐ Stand-alone Tool that adds backup to
Windows Azure capabilities and backup encryption to prior versions of SQL Server
• Benefits‐ One Cloud Backup strategy across prior
versions of SQL Server including 2005, 2008, and 2008 R2
‐ Adds backup encryption to prior versions, locally or in the cloud
‐ Takes advantage of backup to Azure
‐ Easy configuration
Managed backup to Azure
• What’s being delivered‐ Agent that manages and automates SQL
Server backup policy
• Main benefit‐ Large-scale management and no need to
manage backup policy Context-aware – for example, workload/throttling Minimal knobs – control retention period Manage whole instance or particular databases
‐ Take advantage of backup to Azure Inherently off-site Geo-redundant Minimal storage costs Zero hardware management
Example:
EXEC smart_admin.sp_set_db_backup @database_name='TestDB', @storage_url=<storage url>, @retention_days=30, @credential_name='MyCredential', @enable_backup=1
SQL Server 2014Database Data and Log Files in Azure Storage
SQL Server data and log files in Windows Azure storage
• What’s being delivered‐ Ability to move data and log files in Windows
Azure Storage, while keeping the compute node of SQL Server on-premises
‐ Transparent Data Encryption (TDE) is supported
• Main benefits‐ No application changes required‐ Centralized copy of data and log files ‐ Enjoy unlimited storage capacity in Azure
Storage (built in HA, SLA, geo-DR)‐ Secure because TDE encryption key can be
stored on-premises‐ Restore database is simply an attach
operation
SQL Server data and log files in Windows Azure storageCreate database syntax does not change:Restore is simply an attach operation:
SQL Server 2014Deploy Database to Windows Azure Wizard
Easy on-ramp to cloud
Easily migrate on-premises SQL Server to a Windows Azure VM
Designed for users unfamiliar with Windows Azure
Ideal for existing apps and dev/test new apps
Full SQL Server functionality
Full VM control
Ideal for new variable-demand apps
Dynamic scale-out of database
No patching of OS or DB
Built-in HA with 99.9-percent SLA
DB
Deploy databases to Windows Azure VM
• What’s being delivered‐ New wizard to deploy databases to
SQL Server in Windows Azure VM‐ Can also create a new Windows Azure
VM if needed
• Main benefits‐ Easy to use
Perfect for database administrators new to Azure and for ad hoc scenarios
‐ Complexity hidden Detailed Azure knowledge not needed Almost no overhead: defining factor
for time-to-transfer is database size
Call to action
• Download Trial SQL Server 2014 http://technet.microsoft.com/en-US/evalcenter/dn205290.aspx
• Trial Azurehttp://azure.microsoft.com/en-us/pricing/free-trial/
• SQL Serverhttp://www.microsoft.com/SQLServer
top related