Over the course of the last couple of months I’ve come across some things in SQL Server that I’ve never really thought about.
“..” implies the default schema for A user.
If you have a user in a database with say a default schema of “Production” writing this:
SELECT ProductCode, ProductName, ProductColour FROM CompanyDB..Products
Actually implies the Production schema.
The TempDB can really cause problems if it’s not configured correctly.
More of a reminder this one. I’ve recently worked on a client who was having some performance issues with a reporting tool. When they ran extracts from a SQL database it wasn’t very fast. I tried it myself and agreed it wasn’t performing as well as it should.
The reporting tool is heavily driven by cursors but let’s not get started on those. I looked in Activity Monitor and noticed quite a lot of contention on the TempDB. A further investigation revealed that there was a total of 1 TempDB for a Octa-core server.
After adding a further 7 TempDB row and log files we found that the reporting tool ran much much quicker and the contention was gone.
You can alias without using “As”
This one probably isn’t “best practice” but you can write:
SELECT C.CustomerID, C.Name, C.Address1, C.City FROM Customers AS C
As:
SELECT C.CustomerID, C.Name, C.Address1, C.City FROM Customers C
I don’t like doing this because to me that’s breaking a general principle of keeping script readable plus the reason I’ve never known about this is because all the T-SQL books and resources I’ve read have NEVER mentioned this is correct syntax so they must also consider it a no-no.
You stand a good chance of recovery if your server doesn’t boot but you’ve still got the SQL data.
I recently helped a client that lost a SQL data warehouse server to a Windows update that somehow caused it to not boot. They managed to pull all the files off the volumes so we had all the user databases as well as master and msdb databases.
The client was on a tight budget so we raced against time to get the server going as quick as possible. I was surprised to see that simply dropping in the master and msdb databases over the ones installed on the new server (shut the SQL Server instance down first) and putting the user databases at the original location restored pretty much all settings and data.
Of course you’ll run into problems if there was some encryption in use and you’ll need to use the same SQL Server release but other than that it proved a seemingly OKish way to restore the client’s data warehouse quickly.
