Azure SQL Type Database Flashcards
What are the types of Azure SQL Databases (MS)
SQL on a Virtual Machine
Azure SQL Managed Instance
– General purpose
– Buisness critical
Azure SQL Database
– General purpose
– Buisness critical
– Elastic pool
Azure SQL Database (hyperscale)
– General purpose
– Buisness critical
– Elastic pool
When should I use Azure SQL Managed Instance?
Most compatible, suitable for lift and shift.
Azure SQL Managed Instance is an ideal choice when you need a fully managed SQL Server instance in the cloud that supports the following scenarios:
Easy Lift-and-Shift for On-Premises SQL Server Workloads: SQL Managed Instance offers near-full compatibility with on-premises SQL Server, making it an excellent option for migrating existing SQL Server workloads with minimal application or database refactoring.
Extended SQL Server Features: SQL Managed Instance includes features not available in Azure SQL Database, such as SQL Agent, cross-database queries, and Service Broker, which are useful for applications with dependencies on these features.
High Availability and Built-In Disaster Recovery: SQL Managed Instance supports built-in high availability and offers options for automated backups, point-in-time restore, and geo-redundancy, making it well-suited for applications with strict recovery time objectives (RTO) and recovery point objectives (RPO).
Network Isolation and Enhanced Security: If you need to isolate your database within a private network and integrate it with on-premises resources, Managed Instance can be deployed within a virtual network (VNet), enabling private IP access and additional security configurations.
Compliance with Enterprise Requirements: Managed Instance supports compliance requirements for businesses needing features like Azure Active Directory (Entra ID) authentication, Transparent Data Encryption (TDE), and Advanced Threat Protection (ATP).
Scaling for Enterprise Workloads: Managed Instance provides scaling options in terms of both compute and storage, which is beneficial for enterprise applications with demanding performance and storage requirements.
Hybrid Cloud and Application Modernization: If you’re looking to modernize a portion of an on-premises SQL Server setup while keeping certain components in the cloud, Managed Instance allows for seamless integration and hybrid setups with features like Linked Servers and cross-premises connectivity.
When should I use Azure SQL Database elastic pools?
Best fit for modern cloud applications where you can change the application code to account for not having full SQL server capabilities.
Also when having several databases thet wnat to spread the available resources across the databases because several databases are not all taking resources at once.
Azure SQL Database elastic pools are a great choice when you have multiple databases that:
Have variable and unpredictable usage patterns: If your databases have varying or unpredictable demand, elastic pools allow you to balance the performance cost across multiple databases, making it cost-effective.
Need resource sharing and cost savings: Elastic pools let multiple databases share a set of resources (DTUs or vCores) at a fixed price. This can be more economical than provisioning resources for each database individually, especially if some databases have low or intermittent usage.
Have databases with a single-tenant or multi-tenant SaaS model: In multi-tenant SaaS scenarios, where each tenant might have its database, elastic pools allow for predictable costs while supporting varying tenant usage.
Require scaling for numerous databases: Elastic pools allow you to manage and scale a group of databases easily without scaling each database individually. This can simplify operations if you have multiple databases with similar performance needs.
Operate under a fixed budget: By placing multiple databases into an elastic pool, you can control costs while providing enough resources to handle varying workload demands across the databases.
When is it best to use Azure SQL Virtual Machines?
Best fit when you need operating system level access and the most compatability.
Who is responsible for patching the operating system when using Azure SQL on virtual machines?
You are responsible for patching.
When using Azure SQL on virtual machines (SQL Server on Azure VMs), the customer is responsible for patching the operating system. Azure provides platform-managed services to assist with SQL Server updates and maintenance, but the underlying VM and OS are managed by the customer, including OS patches and updates.
In contrast, Azure SQL Database (a fully managed PaaS offering) handles both OS and database patching as part of the service, reducing the customer’s maintenance burden.
Who is responsible for patching when using Azure SQL Database?
When using Azure SQL Database, Microsoft is responsible for patching the operating system, database engine, and all underlying infrastructure. This is part of the fully managed platform-as-a-service (PaaS) model, which includes regular updates, patches, and backups to ensure availability, security, and compliance.
When using Azure SQL on virtual machines, what VM type should you be considering?
Consider a memory-optimized virtual machine.
Storage-optimized virtual machine.
How can you quickly back up the VM running your SQL on a virtual machine?
To quickly back up a VM running SQL Server on a virtual machine in Azure, you can follow these steps:
- Use Azure Backup for VM-level Backup
Azure Backup can perform a backup of the entire VM, including the OS and data disks. This backup is typically file-system consistent (not application-consistent) by default, meaning it’s not aware of the SQL Server state.
Steps to back up a VM with Azure Backup:
Go to the Azure portal.
Navigate to Backup Center or search for Backup.
Create a Recovery Services Vault if you don’t have one.
In the vault, select Backup and then choose Azure Virtual Machine as the backup item.
Select the VM running SQL Server and configure the backup schedule.
Run an immediate backup or let the backup run on the schedule you’ve set.
Important Note: This backup will capture the VM at the disk level but is not SQL Server-aware (it’s file-system consistent).
- Use SQL Server Backup for Application-Consistent Backup
If you need application-consistent backups, you should also back up the SQL Server databases while the VM is running. This ensures that the SQL Server database files (including transaction logs) are in a consistent state and recoverable.
Use SQL Server Management Studio (SSMS) or Transact-SQL (T-SQL) commands to back up the databases. You can back up the database files using BACKUP DATABASE and include transaction logs (BACKUP LOG).
You can schedule these backups or trigger them manually as needed.
Example:
BACKUP DATABASE [YourDatabase] TO DISK = N’C:\Backup\YourDatabase.bak’
WITH INIT;
BACKUP LOG [YourDatabase] TO DISK = N’C:\Backup\YourDatabase_log.trn’;
3. Use Azure Backup with SQL Server Integration (Application-Consistent Backup)
For more seamless integration, you can enable SQL Server-aware backups through Azure Backup. This provides an application-consistent backup that takes SQL Server into account (ensuring that transaction logs and open transactions are handled).
In Azure Backup, enable SQL Server protection in the Recovery Services Vault.
Select the VM running SQL Server and configure SQL Server backup options.
Azure Backup will back up the SQL Server databases in an application-consistent manner, ensuring that the SQL Server transaction logs and database states are consistent.
4. Use VM Snapshot for Quick Backups (Not SQL Consistent)
A snapshot of the VM disk is another option for a quick backup, but keep in mind that snapshots are not application-consistent. It’s a quick way to back up the VM, but to ensure SQL Server data consistency, you need to ensure that SQL Server has flushed transaction logs before taking the snapshot.
To take a snapshot:
In the Azure portal, navigate to your VM.
Go to the Disks section and select the disk you want to back up.
Click on Create snapshot.
Configure the snapshot and create it.
This is a quick method, but again, it’s not suitable for SQL Server database consistency unless done in conjunction with SQL Server-aware backup methods.
Key Points:
Azure Backup provides a simple method for VM-level backup but is not application-consistent by default for SQL Server.
SQL Server native backups (via SSMS or T-SQL) provide application-consistent backups for SQL databases.
You can combine SQL Server backup with Azure Backup for an application-consistent VM backup.
For mission-critical SQL Server applications, it’s important to ensure the backup is both file-system consistent and SQL Server application-consistent, typically achieved through SQL Server-aware backups.
What is Azure SQL Database latency when data stays in the same region as going to a secondary?
All data passing over the network in a region is less than 2ms.
Explain how availability is achieved for the general-purpose tier for Azure SQL Database and Azure SQL Instance?
Data from the primary is stored in Azure Blob Storage, and there are three replicas; if the primary node compute fails, there are spare nodes kept available in the regional and one will be selected and pointed to the storage and booted to replace the failed primary
Explain how availability is achieved for the business-critical tier for Azure SQL Database and Azure SQL Instance.
The business-critical data is stored on the node’s local disk, with several secondary nodes; data is sync replication and acknowledged from at least one node. This is called SQL always on
Where is data stored when using the business-critical tier for Azure SQL Database and Azure SQL Instance?
Node local storage
Where is data stored when using the general-purpose tier for Azure SQL Database and Azure SQL Instance?
Azure Blog Storage
Explain always-on the context of Azure SQL Database and Azure SQL Instance?
In always-on, data is replicated between primary and secondary replicas; data can be synced or async.
What the the tiers available in Azure SQL?
General-purpose
Buisness-critical
Hyperscale
When would I use the General-Purpose Tier?
- Most general-purpose workloads
- moderate performance needs.
- Budget-friendly: Provides cost-effective options.
- Storage: Uses Azure Premium SSD for storage, with up to 8 TB of database size.
- Availability: Provides high availability using the Always On availability groups with automated backups and replication.
- Sutable for: Applications with standard OLTP workloads.
- Sutable for: Moderate transaction rates and throughput.
- Sutable for: Applications that need balanced performance at a lower cost.
How is High-Availability achieved for the General-Purpose Tier for Azure SQL Database?
Availability: Provides high availability using the Always On availability groups with automated backups and replication.
What workload is suitable for the General-Purpose Tier for Azure SQL Database?
- Most general-purpose workloads
- Moderate performance needs.
- Budget-friendly: Provides cost-effective options.
What workload is suitable for the General-Purpose Tier for Azure SQL Instance?
- Most general-purpose workloads
- Moderate performance needs.
- Budget-friendly: Provides cost-effective options.
What workload is suitable for the General-Purpose Tier for Azure SQL Instance?
- Applications with standard OLTP workloads.
- Moderate transaction rates and throughput.
- Applications that need balanced performance at a lower
What workload is suitable for the General-Purpose Tier for Azure SQL Database?
- Applications with standard OLTP workloads.
- Moderate transaction rates and throughput.
- Applications that need balanced performance at a lower
What are the purchasing models available for both Azure SQL Database and Instance?
- vCore
- DTU
For the purchasing model for both Azure SQL Database and Instance, what is the MS recommended model?
We recommend the vCore-based model because it allows you to independently select compute and storage resources. The DTU-based model is a bundled compute, storage, and I/O resource measure.
What SSD types are used with the General-Purpose Tier for Azure SQL Database?
Azure Premium SSD for storage (Blob Storage)
What SSD types are used with the General-Purpose Tier for Azure SQL Instance?
Azure Premium SSD for storage (Blob Storage)
What SSD types are used with the Buisness-Critical Tier for Azure SQL Database?
Uses local SSDs to offer low-latency reads and writes.
What SSD types are used with the Buisness-Critical Tier for Azure SQL Instance?
Uses local SSDs to offer low-latency reads and writes.
How is High-Availability acheived for the Business-Critical Tier for Azure SQL Database?
High availability: Three replicas in the primary region ensure higher availability. In this case, three replicas are in the same area with the same data, and data is synced using the sync process.
How is High-Availability acheived for the Business-Critical Tier for Azure SQL Instance?
High availability: Three replicas in the primary region ensure higher availability. In this case, three replicas are in the same area with the same data, and data is synced using the sync process.
For Azure SQL Database, explain backups.
- Azure SQL Database automatically creates
- Full Backup: Taken once a week.
- Differential Backup: Taken every 12 to 24 hours.
- Transaction Log Backup: Taken every 5 to 10 minutes.
- Stored in geo-redundant storage (GRS) by default, ensuring high availability and disaster recovery capabilities.
For Azure SQL Database, what are the backup retention periods?
- Basic Tier: Backups are retained for seven days.
- Standard and Premium Tiers: Backups are retained for 35 days.
- Long-Term Retention (LTR): You can configure long-term retention for up to 10 years if needed, by moving backups to Azure Blob Storage.
For Azure SQL Database, do you select the retention periods?
- Basic Tier: Backups are retained for 7 days.
- Standard and Premium Tiers: Backups are retained for 35 days by default.
- Custom retention period up to 10 year
Can I restore the Azure SQL Database to any point in time? If so, please explain.
You can restore the database to any point in time within the retention period. This feature helps recover from accidental data changes or corruption.
For Azure SQL Instance, explain backups?
- Azure SQL Instance automatically creates
- Full Backup: Taken once a week.
- Differential Backup: Taken every 12 to 24 hours.
- Transaction Log Backup: Taken every 5 to 10 minutes.
- Stored in geo-redundant storage (GRS) by default, ensuring high availability and disaster recovery capabilities.
For Azure SQL Instance, explain backup retention?
- Automated backups are retained for 7 to 35 days, depending on your configuration and service tier.
2.Long-Term Retention (LTR): Similar to Azure SQL Database, you can configure long-term retention for up to 10 years.
For Azure SQL Database, what pricing tiers are available?
- vCore: General Purpose
- vCore: Business Critical
- vCore: Hyperscale
- DTU: Basic
- DTU: Standard
- DTU: Premium
Does Azure SQL Managed Instance support SQL Server Integration Services?
Yes, SQL Server Integration Services (SSIS) is supported
Does Azure SQL Database support SQL Server Integration Services?
Azure SQL Database does not support SQL Server Integration Services (SSIS) directly. SSIS is not natively hosted on Azure SQL Database, which means you cannot run SSIS packages directly within Azure SQL Database itself. However, there are alternative approaches to using SSIS with Azure SQL Database:
- Azure Data Factory: You can use Azure Data Factory (ADF) with the SSIS integration runtime to run SSIS packages in the cloud. ADF provides a managed SSIS service that enables you to host, execute, and manage SSIS packages, allowing you to connect to Azure SQL Database as part of your ETL (Extract, Transform, Load) workflows.
- On-premises SSIS: If you have SSIS running on-premises, you can still connect to Azure SQL Database as a data source or destination by configuring the connection in your SSIS packages to point to your Azure SQL Database instance.
- SQL Managed Instance: If you need native support for SSIS, you might consider Azure SQL Managed Instance, which offers a broader range of SQL Server features, including the ability to host SQL Agent jobs to run SSIS packages.
In short, while Azure SQL Database does not natively support SSIS, you can use Azure Data Factory or host SSIS packages on-premises or in a managed instance to interact with Azure SQL Database.
Does Azure SQL Instance support Cross Database transactions?
Yes, Azure SQL Managed Instance supports cross-database transactions. This feature allows you to perform operations across multiple databases within the same managed instance using traditional Distributed Transaction Coordinator (DTC) support. This capability is useful for complex applications that require transactional consistency across several databases.
However, for cross-instance or cross-server database transactions (e.g., between different Azure SQL Managed Instances or an on-premises SQL Server and Azure SQL Managed Instance), you would need to configure additional components, such as Azure SQL Database elastic transactions, or use alternative methods, as DTC is only supported within the boundaries of a single managed instance.
Does Azure SQL Instance support Linked Services?
Yes, Azure SQL Managed Instance supports linked servers. Linked servers in Azure SQL Managed Instance allow you to connect to and query external data sources directly from the SQL Managed Instance, just as you would in an on-premises SQL Server.
With linked servers, Azure SQL Managed Instance can connect to other SQL Servers, Azure SQL Databases, or even non-SQL data sources, enabling distributed queries and data integration across different environments.
For setting up linked servers in Azure SQL Managed Instance, you typically need:
Credentials for authentication.
Network configurations that permit connectivity to the external source.
Transact-SQL (T-SQL) configuration steps to define and manage the linked server settings.
This feature makes Azure SQL Managed Instance a flexible choice for hybrid and multi-cloud database scenarios where integration with external databases is required.
Does Azure SQL Instance support CLR?
Yes, Azure SQL Managed Instance supports the CLR (Common Language Runtime) integration. This feature allows you to create user-defined functions, stored procedures, triggers, and aggregates in managed code, such as C# or VB.NET, which can then be executed within SQL Managed Instance. It’s especially useful for more complex logic and custom functions that may be difficult to achieve with T-SQL alone.
Does Azure SQL Instance support Service Broker?
No
Does Azure SQL Instance support SQL Server Replication?
No, Azure SQL Managed Instance does not support Service Broker. While Service Broker is available in SQL Server on-premises for managing asynchronous messaging and processing, this feature is not supported in Azure SQL Managed Instance or Azure SQL Database.
For similar functionality, you may consider using alternatives like Azure Service Bus or Azure Queue Storage, which provide reliable messaging and queueing capabilities suitable for cloud applications
Does Azure SQL Instance support Database Mail?
No
Does Azure SQL Instance support Stretch Database?
No
Does Azure SQL Instance support Data Quality Service?
No
What is the upper limit to retain automatic backups for Azure SQL Database and Azure SQL Instance?
10year
How are backups handled in Azure SQL Instance?
- Backups are automatic
- Full weekly backup
- Diff backups every 12 - 24 hrs
- Transaction log backups every 5 - 10 min
How long are backups retained in Azure SQL Instance?
- Default retention is 7 to 35 days
- Long Term Retention up to 10 years
Explain how to recover a recent backup in Azure SQL Instance?
- Use point-in-time restore
How are backups handled in Azure SQL Instance?
- Backups are automatic
- Full weekly backup
- Diff backups every 12 - 24 hrs
- Transaction log backups every 5 - 10 min
How long are backups retained in Azure SQL Instance?
- Default retention is 7 to 35 days
- Long Term Retention up to 10 years
Explain how to recover a recent backup in Azure SQL Instance?
Use point-in-time restore
Do I manually tune for performance for the Azure SQL Instance and Database performance?
No it is automatic performance tuning
Should I be concerned about the database version for the Azure SQL Instance?
No, the Azure SQL Instance is updated by MS to the latest release to fix issues.
1. Latest version
2. Version less
Should I be concerned about the database version of the Azure SQL Database?
No, the Azure SQL Database is updated by MS to the latest release to fix issues.
1. Latest version
2. Version less
I wnat to use the Azure Hybrid Benefit model with Azure SQL Database and Instance; what purchasing model should I use?
Use the vCore model
Can I use Hybrid Benefits with Azure SQL?
Yes
You have a web application that uses Azure SQL Database as its backend. The database contains sensitive customer data that must be protected from unauthorized access. It would be best to recommend a solution implementing row-level security (RLS) in the database. The solution must meet the following requirements: * Allow users to access only the data that is relevant to them. * Ensure that users cannot access data that is not relevant to them. * Minimize the amount of administration required to manage the security. What should you include in the recommendation?
RLS is a feature in Azure SQL Database that restricts data access for specific rows in a table, based on the characteristics of the user executing the query. RLS ensures that users can only view and manipulate rows of data they are authorized to access, which aligns perfectly with the requirement of allowing users to access only the relevant data.
Explain how RLS works in Azure SQL Database?
- Security Policies: You define a security policy that enforces the restrictions for each query executed by a user. This policy can include a predicate that is evaluated for each query.
- Filter Predicate: A function returns a boolean value to decide which rows the user can access. This predicate is applied every time a query runs on a table with RLS enabled.
- Block Unauthorized Access: Users will automatically be blocked from accessing rows that do not match the filter predicate.
Explain how RLS is used in the Azure SQL Database?
Query data is filtered based on user, so the users only return a subset of the database data.
Explain an Azure SQL Instance SQL Server-level Firewall Rule?
Controls access to the entire network ranges or specific IP addresses across all databases under the server. This is beneficial for managing multiple applications or clients accessing different databases but sharing the same security policies.
Using SQL Server-level Firewall Rule, can you specify a database to an IP?
No, SQL Server-level firewall rules in Azure SQL cannot be used to specify access to a single database for a particular IP address. These rules operate at the server level, meaning they control access for all databases under the server. Once an IP address is allowed at the server level, that IP can access any database on that server, provided the user has the necessary authentication and permissions.
When using Azure SQL Service Instance SQL Server-level Firewall Rules, what is the scope of the rules?
All databases belong to the server.
I have three databases running on an Azure SQL server instance; how can I ensure that IP1 for DB1 and IP2 for DB2, and IP3 for DB3?
Use Database-level Firewall Rules
What is Always-Encrypted Client-Side Encryption?
The encryption and decryption process happens on the client side. Sensitive data is never visible to the database or database administrators in plaintext.
What is Always-Encrypted Column-Level Encryption Encryption?
You can encrypt specific sensitive columns (e.g., credit card numbers, social security numbers) in a table while leaving the rest of the data unencrypted.
What is Always-Encrypted Separation of Roles ?
Always Encrypted helps to separate the roles between the application developers or administrators and the database administrators. Database administrators have access to the database but do not have access to the encryption keys and thus cannot view sensitive data in plaintext.
What is Always-Encrypted Encryption Types?
Deterministic Encryption: Always produces the same encrypted value for the same plaintext value. This allows equality searches but may reveal patterns.
Randomized Encryption: Produces different encrypted values for the same plaintext value, providing better security but does not support equality searches.
What is Always-Encrypted Transparent to Applications Encryption?
Applications can interact with the data without needing to be aware of the encryption process. The client driver (e.g., ADO.NET) transparently handles encryption and decryption when configured with the necessary keys.
What is Always-Encrypted Transparent Keys and Key Management?
There are two key types used:
Column Encryption Key (CEK): Encrypts the actual data.
Column Master Key (CMK): Encrypts the CEK. The CMK is stored in an external key store (e.g., Azure Key Vault).
When using an auto-failover group, can you have a data loss?
Yes, 5 seconds
When using an auto-failover group, can you use the secondary for both read and write?
No, only read.
When using an auto-failover group, should the secondary be in a separate resource group?
No, its a requirment to have both primary and secondary in same resource group.
When using an auto-failover group, should you locate both primary and secondary in the same region?
No, separate regions.
Are server-side transaction supported for Azure SQL Managed Instance?
Yes
Can you have a private vNET and deploy Azure SQL Database?
No, deploying Azure SQL is supported, but you could have a private or service endpoint to the SQL service or the database.
Is Azure SQL Managed Instance a single-tenant environment?
Yes, Azure SQL Managed is a single-tenant environment