To test the throughput I will run a set test with the TempDB database on D:\ (local SSD) and then rerun the test again with the TempDB moved onto F:\ (P30 premium disk). Between the tests SQL Server is restarted so we’re starting with a clean cache and state.
The test SQL script will create a temporary table and then run a series of insert, update, select and delete queries against that table. We’ll then capture and record the statistics and time.
The results were interesting; read on to learn more.
The Spark-Hbase Connector provides an easy way to store and access data from HBase clusters with Spark jobs. HBase is really successful for highest level of data scale needs. Thus, existing Spark customers should definitely explore this storage option. Similarly, if the customers are already having HDinsight HBase clusters and they want to access their data by Spark jobs then there is no need to move data to any other storage medium. In both the cases, the connector will be extremely useful.
I’m not the biggest fan of HBase, but if it’s part of your environment, you should definitely look at this Spark connector.
Now for the big question, Windows or Linux?
That’s absolutely correct.
As you can see, we now have a new path in our query plan with an operator called “Remote Query”. Basically the local server queries the remote query then using the local Primary key Concatenates them back together to produce the desired result. So can we update the data?
Nope, sure can’t. Once the data lives in Azure, the data is READ ONLY.
Check it out. He’s a bit more sanguine about Stretch than I am, so maybe it will fit your use cases.
In brief, SQL DW is a fully managed data-warehouse-as-a-service that you can provision in minutes and scale up in seconds. With SQL DW, storage and compute scale independently. You can dynamically deploy, grow, shrink, and even pause compute, allowing for cost savings. Also, SQL DW uses the power and familiarity of T-SQL so you can integrate query results across relational data in your data warehouse and non-relational data in Azure blob storage or Hadoop using PolyBase. SQL DW offers an availability SLA of 99.9%, the only public cloud data warehouse service that offers an availability SLA to customers.
The pricing calculator now reflects GA prices.
One of the biggest frustrations that people find with SQL DW is that you need (or rather, needed) to use SSDT to connect to it. You couldn’t use SSMS. And let’s face it – while the ‘recommended’ approach may be to use SSDT for all database development, most people I come across tend to use SSMS.
But now with the July 2016 update of SSMS, you can finally connect to SQL DW using SQL Server Management Studio. Hurrah!
…except that it’s perhaps not quite that easy. There’s a few gotchas to be conscious of, plus a couple of things that caused me frustrations perhaps more than I’d’ve liked.
Yes, it’s never quite that easy… Read the whole thing.
I’m happy to announce Always Encrypted in Azure SQL Database is now generally available!
Always Encrypted is a feature designed to ensure sensitive data and its corresponding encryption keys are never revealed in plaintext to the database system. With Always Encrypted enabled, a SQL client driver encrypts and decrypts sensitive data inside client applications or application servers, by using keys stored in a trusted key store, such as Azure Key Vault or Windows Certificate Store on a client machine. As a result, even database administrators, other high privilege users, or attackers gaining illegal access to Azure SQL Database, cannot access the data.
To be honest, I’d much rather try Always Encrypted against an Azure SQL Database instance than an on-premise instance, mostly because if I hose Azure SQL Database that badly or the company decides that Always Encrypted isn’t a good fit, I can grab the data and dump the instance. It’s a little harder to do that with physical hardware or even an on-prem VM.
Azure Automation is essentially a hosted PowerShell script execution service. It seems to be aimed primarily at managing Azure resources, particularly via Desired State Configurations.
It is, however, a general PowerShell powerhouse, with scheduling capabilities and a bunch of useful features for the safe storage of credentials etc. This makes it an excellent tool if you’re looking to do something with PowerShell on a regular basis and need to interact with Azure.
Read the whole thing.
Currently, when utilizing the SQL Server images in the VM Gallery in Azure, any installations of SQL Server Analysis Services default to Multidimensional. Thus, if you want SSAS Tabular, you have additional work to perform.
I was just chatting with a Senior Program Manager on the SQL Server Analysis Services product team. They currently don’t have anything in their plans for providing SQL Server Gallery Images with SSAS Tabular instead of Multidimensional. We agreed that it is a good idea for that to happen. We also agreed that a Connect suggestion would be a great way to gauge broader community support/appetite for providing Gallery images with Tabular installed.
When you create VM from a captured image, the drive letters for data disks may not preserved. For example if you have system database files on E: drive, it may get swapped to H: drive. If this is the case, SQL Server can’t find system database files and will not start. If the driver letter mismatch occurs on user database files, then the user databases will not recover. After VM is created, you just need to go to disk management to change the drive letters to match your original configuration.
Read the whole thing if you’re thinking about copying your on-premise server to an Azure VM.