07Aug 2017 by Grant Fritchey 2 Comments

Database Fundamentals #7: Create a Table Using T-SQL

Database Fundamentals, T-SQL
The syntax for creating a table logically follows many of the same steps that you did when using the GUI, but it will all be done with the statements. This script will exactly replicate everything that you did with the GUI: CREATE TABLE dbo.Person ( PersonID int IDENTITY(1,1) NOT NULL, FirstName varchar(50) NOT NULL, LastName varchar(50) NOT NULL, DateOfBirth date NULL ) ON [PRIMARY]; Breaking the script into separate lines, it’s easy to see how the TSQL commands perform the actions defined in the GUI (it also makes it easier to read). The CREATE TABLE statement in this context is self-explanatory.  After that you’re defining the schema and the table name. Within the parenthesis you define each of the columns. First is the name of the column followed by the…
Read More
24May 2016 by Grant Fritchey 3 Comments

On the Buckeye Blitz!

T-SQL
In just a few weeks I'll be doing the Buckeye Blitz. That is, a tour of user groups in Ohio (aka, the Buckeye state, after a tree, not a sports team), one per day across a week. Here's how it breaks down: Cleveland: 6/13 Toledo: 6/14 Columbus: 6/15 Cincinnati: 6/16 I'll be talking on this topic at each of the groups: Change Your Habits: Tips to Tune Your T-SQL T-SQL proides many different ways to accomplish the same task, and as you might expect, some ways are better than others. In this session, you will learn specific techniques, that when followed make you a better T-SQL developer. The session is jam-packed with practical examples and is designed for administrators and developers who want to bring their T-SQL skills to the…
Read More
06Apr 2015 by Grant Fritchey 8 Comments

Constraints and SELECT Statements

Azure, SQL Server, T-SQL
I've posted previously about how a foreign key constraint can change how a SELECT query behaves. Logically that just makes sense. But other types of constraints don't affect execution plans do they? Yes. Let's take this constraint as an example: ALTER TABLE Sales.SalesOrderDetail WITH CHECK ADD  CONSTRAINT CK_SalesOrderDetail_UnitPrice CHECK  ((UnitPrice>=(0.00))) That will ensure that no values less than zero can slip in there. We can even validate it: INSERT Sales.SalesOrderDetail (SalesOrderID, CarrierTrackingNumber, OrderQty, ProductID, SpecialOfferID, UnitPrice, UnitPriceDiscount, rowguid, ModifiedDate ) VALUES (60176, -- SalesOrderID - int N'XYZ123', -- CarrierTrackingNumber - nvarchar(25) 1, -- OrderQty - smallint 873, -- ProductID - int 1, -- SpecialOfferID - int -22, -- UnitPrice - money 0.0, -- UnitPriceDiscount - money NEWID(), -- rowguid - uniqueidentifier GETDATE() -- ModifiedDate - datetime ); Will give me…
Read More
03Sep 2014 by Grant Fritchey 12 Comments

Left or Right?

SQL Server, T-SQL
No, this is not about politics. It's about your WHERE clause... and your JOIN criteria... and your HAVING clause. It's about a canard that still makes the rounds occasionally. Please, help me put this statement to sleep for once and all: A function on the left side of the equals sign can lead to performance problems Well, you know, it's sort of true. But then, a function on the right side of the equals sign can also lead to performance problems. In short, it's not the placement of the function that causes issues, it's the function that causes issues. Let's take a look at a really simple example: SELECT a.AddressID, a.AddressLine1, AddressLine2 FROM Person.Address AS a WHERE a.AddressLine1 = 'Downshire Way'; This simple query results in an equally simple execution plan: Now,…
Read More
19Mar 2014 by Grant Fritchey No Comments

Query Tuning Near You

SQL Server, T-SQL
It really is so much easier to just throw hardware at badly performing databases. Just buy a bigger, faster server with more and faster disks and you can put off doing tuning work for another 6-9 months, easily. But, for most of us, sooner or later, our performance problems get so big or, we just don't have any more money to spend, and we're stuck. We have to tune the queries. And frankly, query tuning is a pain in the nether regions. But, after you've tuned queries 20 or 30 times, you start to recognize the patterns and it gets easier (never easy, just not as hard). But, if you haven't done it 20 or 30 times, what do you do? My suggestion, talk to someone who has done it…
Read More
12Feb 2014 by Grant Fritchey 1 Comment

SQL Server 2014 and the New Cardinality Estimator

Uncategorized
Cardinality, basically the number of rows being processed by an operation with the optimizer, is a calculation predicated on the statistics available for the columns in question. The statistics used are generally either the values from the histogram or the density. Prior to SQL Server 2014, and going all the way back to SQL Server 7.0 (in the Dark Ages when we had to walk uphill to our cubicles through 15 feet of snow battling Oracle DBAs and Fenris the whole way), there's been one cardinality estimator (although you can modify the behavior somewhat with a traceflag in 2008R2 and 2012). Not any more. There's a possibility for really complex, edge-case queries, that you may run into a regression from this. You control whether or not you get the new…
Read More
28Aug 2013 by Grant Fritchey No Comments

Learn Query Tuning in Dallas

SQL Server, T-SQL
I am excited to be able to tell you about an all day seminar that I'll be putting on prior to the Dallas SQL Saturday #255. The seminar will be on November 1, 2013. It's called Query Performance Tuning in SQL Server. We're going to cover the topic from an understanding of the optimizer to collecting data using extended events to reading execution plans and then on to lots of standard problems and their solutions. If you sign up before September 21st you can get a substantial early-bird discount, so I'd jump on it. Also, seats are limited, so don't wait too long. Let's get together and talk query tuning.
Read More
07Aug 2013 by Grant Fritchey 7 Comments

Be Cautious When Critizing About Guidance

T-SQL
I recently posted some comments about some guidance offered by Microsoft when talking about the CXPACKET wait type. Nothing I said was wrong, no. But, evidently there are a few whip smart and agile people who work for Microsoft. Specifically, Rick Byham, who works for the team tasked with taking care of the SQL Server Books Online. Why am I calling Mr. Byham smart and agile. Evidently he saw the blog post and has completely updated the description for CXPACKET at MSDN: Occurs with parallel query plans when trying to synchronize the query processor exchange iterator. If waiting is excessive and cannot be reduced by tuning the query (such as adding indexes), consider adjusting the cost threshold for parallelism or lowering the degree of parallelism. WHOOP! That's awesome work. Thanks Mr. Byham. Of…
Read More
24May 2013 by Grant Fritchey 3 Comments

A Little Azure Fun on Friday

Azure, T-SQL
You know how we've always heard that sp_msforeachtable and other similar undocumented functions may not be supported in future versions of SQL Server? Have you tried running something like this on any of your Windows Azure SQL Databases yet: EXEC sp_msforeachtable 'select ''?'', count(*) from ?' Try it out.
Read More
13Feb 2013 by Grant Fritchey 50 Comments

SQL Server Naming Standards

T-SQL
Want to start a fight between a bunch of DBAs or database developers? Ask them where the comma should be placed between columns in a SELECT statement. It's actually a little disturbing just how much emotional value people place in this. Almost as good, tell a database developer you don't like their naming standard. Hoo boy! The purpose of a naming standard, I think most of us can agree, is for clarity. We're defining language so that we all mean the same thing when we say it, right? We want to communicate clearly, so we're going to implement a naming standard. Fine. Sounds good. And then, you get this: dbo.tblDdltbl Umm... Wait. What? And there are hundreds of these, all with the same first three letters, tbl. Oh, wait, I…
Read More