https://docs.microsoft.com/archive/blogs/staltam/feed.xml Go with the data flow Tue, 16 Apr 2019 05:31:06 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/staltam/hey-dbas-powershell-is-your-friend Fri, 11 May 2018 13:39:58 GMT https://blogs.msdn.microsoft.com/staltam/?p=125 sqlps module. Here’s the links to the documentation. https://docs.microsoft.com/en-us/powershell/module/sqlps/backup-sqldatabase?view=sqlserver-ps https://docs.microsoft.com/en-us/powershell/module/sqlps/restore-sqldatabase?view=sqlserver-ps It’s easy to set up a command like this:     and restore the database using something like this:   In this way I can backup and restore databases from one instance to the other in a single place: my PowerShell window. From this point, if you know a little PowerShell, it’s really easy to let PowerShell generates the scripts for you:     Really simple: a query to retrieve all databases, a loop to make substitutions in commands and place them in a powershell script. The result will look like this:   There are lots of Cmdlets in SQLPS, almost everything that you can do in SQL Server Management Studio can be done also in PowerShell. Take a look at the documentation: https://docs.microsoft.com/en-us/powershell/module/sqlps/?view=sqlserver-ps Have Fun. Stefano   Disclaimer: I just want to show an alternative to T-SQL. The commands and the scripts listed above are just for learning purpose, every environment needs a specific assessment. Lots of things needs to be considered. In other words: don’t run them on production environments!  ]]> https://docs.microsoft.com/archive/blogs/staltam/sql-server-updates-behavior Thu, 27 Jul 2017 08:46:11 GMT https://blogs.msdn.microsoft.com/staltam/?p=77 Then write a few updates queries:   A good starting point is the queries execution plans. Here's how a couple of execution plans look like from my update queries: The execution plan is computed before the actual query execution and does not take in account if the fields are to update or not. But in the execution plans there are some “compute scalar” operators. Maybe SQL Server use them to check if the field need to be really updated or not, at least I have a clue. A closer look to the buffer pool will help me to find the answer, here the DMV sys.dm_os_buffer_descriptors comes handy. This DMV returns a description about all the pages that are in SQL Server Buffer pool. The keystone here is colum “is_modified”, that marks dirty pages. My plan is to run a “real” update query and a “matching” update query. After each run check what’s in the DMV. This is the query that I use in this case to check the status of the pages in the buffer pool. To be sure that pages are clean, I will issue a checkpoint before each test.. If i run a "not" update query, pages in the buffer pool stay clean. If I run a "real" update query lots of pages in the buffer pool now are dirty: SQL Server is always efficient! Sadly this not means that your I/O is safe. If you look closer to the execution plans, you will see that SQL Server Engine needs to check if an update is "real" or not, the only way to do it is to perform some reads. If the plan uses a non-clustered index that does not cover the query a lookup in the cluster index is needed. Always check your execution plan to avoid expensive read operations!   Have Fun Stefano   PS: I want to thank my colleague, mentor and dear friend Francesco (check out his blog!) for the wonderful discussion that we had about this topic and the ways to demonstrate it. This is only a quick and simple method!]]> https://docs.microsoft.com/archive/blogs/staltam/how-to-disable-always-encrypted-feature Wed, 05 Apr 2017 17:28:46 GMT https://blogs.msdn.microsoft.com/staltam/?p=45 https://msdn.microsoft.com/en-us/library/mt163865.aspx. I created a little demo to show Always Encrypted to my clients. After that I want to “disable” the feature and bring back my database to the original state. SQL Server Management Studio provides a way to decrypt the data, but i realize how to do it only after some time. My first thought was: let’s create a new table with the same schema, load the plain text data in the new table, drop the crypted version and rename the plain text version. An inelegant solution. I don’t like it and I don't want to use it! I need a different approach. Always Encrypted wizard offers the chance to generate a Powershell Script to set up the encryption to run it in a different moment. This is what SQL Server Management Studio generates for my database:     The 2 more interesting lines are the last cmdlets at line 18 and 19: The first command adds to the variable $encryptionChanges the encryption setting for the field CreditCardNumber on MyTargetTable. The second cmdlet apply the settings on my database. That's the way I like it! A couple of changes in the code and I can decypher the column and have it in plain text: I was happy about the result, but I was struggling how to accomplish the task using SQL Server Management Studio. The answer is very simple: run again the Encryption Wizard and set the "Encryption Type" to plaintext.     Long story short: If you cannot find a way, always remember that the "Script" button can help you!     Have fun!   Stefano]]>