I am working on storing data in Azure SQL Data Warehouse.
I am trying to look at my indexes usage and see execution plans but none of them are shown in SSMS.
Question
Why is there no execution plan in Azure SQL Data Warehouse?
Update
I am using SSMS version 13.0.16106.4 (SQL Server 2016).
There are at least three methods of viewing execution plans for Azure SQL Data Warehouse:
Use the EXPLAIN command before any SQL command to view the text execution plan for that command, eg
EXPLAIN
SELECT * FROM yourTable;
For an example of interpreting these plans see here.
Version of SQL Server Management Studio (SSMS) from 17.5 onwards have support for visual execution plans
Download version 17.x or later. More details here.
Through the Azure portal, which is really a wrapper for DBCC PDW_SHOWEXECUTIONPLAN.
Armed with these three methods, you are now no doubt well equipped to view execution plans for Azure SQL Data Warehouse.
As far as I can tell, Actual execution plans within SSMS do not work in Azure DW, (which changed to Azure Synapse, which changed to SQL Dedicated Pools.) Please prove me wrong.
Related
I migrated from sql server to Azure db.
While migrating I found a job named syspolicy_purge_history, do I also need to implement it on Azure db?
As I found the syspolicy_purge_history job is targeting msdb, but I could not found msdb on Azure. A guidance will be highly appreciated...
You can implement syspolicy_purge_history job in case of azure database and msdb not available for Azure SQL Data Warehouse in your case its applicable and supported all version of msdb database
Syspolicy purge history is the default job that deletes data that is older than the number of days specified in the HistoryRetentionInDays property of Policy Management. This prevents unnecessary space consumption in the MSDB system database.
For your Reference:
sp_syspolicy_purge_history (Transact-SQL)
Migrate SQL Server to Azure SQL Database
Is it possible for me to insert some data from one database to another in Azure sql?
Let's say I have a trigger in db1 that updates some values in db2.
I read about elastic queries but it seems like they are read-only so they don't solve my problem.
You can't use cross-database in Azure Sql Server because databases can't see eachother physically , you could use elastic pools but they are Read Only.
A solution is to use SQL Managed Instance to upload your instance . This supports cross-database queries but it was expensive.
There was some previous discussion here about doing similar:
C# Azure Function trigger when SQL Database has a new row added without polling
There is also the Azure SQL Bindings for Azure Functions but they are input bindings and not triggers and they're still in preview and limited to C#, JavaScript and Python.
Azure SQL bindings for Azure Functions overview (preview)
There was a new announcement last week after MS Build however for Azure SQL Database External REST Endpoints Integration (hopefully they don't refer to it as ASDEREI) but this is currently in preview under Early Adoption Program (EAP).
Announcing the “Azure SQL Database External REST Endpoints Integration” Early Adoption Program
I am attempting to spin up an azure synapse pool in terraform. At present from the documentation found at: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/synapse_sql_pool, it appears you have to use a synapse workspace, which also includes a datafactory integration and powerbi, etc.
Right now we just want to datawarehouse not all the other bells and whistles. As you can see within the Azure Portal, you are free to spin up a synapse analytics DW with or without a workspace (see the right image in the box, "formerly SQL DW"):
When you spin that up, you simply have a standalone DW...
Any insight on just getting the datawarehouse as you can in the portal without the workspace and realted?
I am not a Terraform guy. As for Synapse, you are referring to the new one that is in preview. The new one has the workspace which supports SQL pools, Sparks clusters and Pipelines. Although they are supported, they are not created when you deploy a Synapse workspace.
So you can go ahead and created the workspace and one SQL Pool and you will get what you're looking for: the data warehouse engine, named SQL Pool.
Some extra notes: there are 2 types of SQL data warehouse in Synapse Analytics: SQL Pools and SQL on demand. The first one is provisioned computing and is the traditional one with all the features. SQL on demand is still in preview, doesn't have all the features and is charged by the terabyte processed by your queries.
Happy data crunching!
I'm using this very useful SQLCLR script to make a REST call to an API and save the data on SQL Server on the fly.
I have created a stored procedure that withdraws new data every hour so my data are always updated.
I would like to have all this on Azure so I can then create a Power BI data visualization.
THE PROBLEM:
As soon as I try to transfer the database on Azure I receive this error:
TITLE: Microsoft SQL Server Management Studio
------------------------------
Could not import package.
Warning SQL0: A project which specifies SQL Server 2019 or Azure SQL Database Managed Instance as the target platform may experience compatibility issues with Microsoft Azure SQL Database v12.
Error SQL72014: .Net SqlClient Data Provider: Msg 40517, Level 16, State 1, Line 4 Keyword or statement option 'unsafe' is not supported in this version of SQL Server.
Error SQL72045: Script execution error. The executed script:
CREATE ASSEMBLY [ClrHttpRequest]
AUTHORIZATION [dbo]
FROM 0x4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000000000000000800000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000504500004C0103006D85475F0000000000000000E00022200B0130000026000000060000000000007E45000000200000006000000000001000200000000200000400000000000000060000000000000000A00000000200004C1E01000300608500001000001000000000100000100000000000001000000000000000000000002C4500004F00000000600000FC03000000000000000000000000000000000000008000000C000000F44300001C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000080000000000000000000000082000004800000000000000000000002E7465787400000084250000002000000026000000020000000000000000000000000000200000602E72737263000000FC030000006000000004000000280000000000000000000000000000400000402E72656C6F6300000C000000008000000002000000
(Microsoft.SqlServer.Dac)
------------------------------
BUTTONS:
OK
------------------------------
This happens because Azure SQL has some feature stripped off like SQLCLR or SQL Server Agent (for some obvious security reason).
Is there any alternative to SQLCLR on Azure?
Is there any alternative to SQL Server Agent on Azure?
Basically: how to automate a REST call to an API every hour and save the result to SQL Server on Azure?
I do not think there is a straight forward replacement for SQL CLR. However, there are some Azure offerings that might be interesting.
I suppose an alternative is using a scheduled azure function that calls the API and store the result in the Azure SQL Database.
Do mind that if the process takes longer than 10 minutes you cannot use a consumption plan for the Azure Function, which is the most cost effective probably.
Depending on the scenario, Azure Data Factory can also provide a solution. You can create a pipeline that calls the API and copies the data to Sql Server as outlined here, based on a schedule trigger.
Even though Azure Functions is great, you could even solve this without much code using Azure Logic Apps, a scheduled trigger, the http request and the mssql connector.
https://azure.microsoft.com/de-de/services/logic-apps/
We are investigating moving to a cloud model and the Microsoft Azure PaaS platform.
Our current data layer is written using LINQ to SQL. Will it be compatible with SQL Azure?
Yes LINQ to SQL is compatible. But you have to keep 2 things in mind:
SQL Azure is not a dedicated machine for you alone. Your databases will run on machines with other customers. You may be throttled, you can encounter transient exceptions, ... That's why you should implement a retry policy. There's an article on TechNet explaining how to do this with LINQ to SQL.
Since SQL Azure is not a real SQL Server there are some limitations. Read all about those limitations here: General Guidelines and Limitations (Windows Azure SQL Database). If you're planning to move an existing database (with or without data) to SQL Azure, consider using a tool that supports SQL Azure like the SQL Database Migration Wizard (SQLAzureMW).