Effectively Designing a Scalable and Reliable Database
A Primer to Proper SQL Server Development
SQL Server Mixed Workloads, Secondary Databases, Locking and Isolation, Part 6 of 10
Presented by Kimberly L. Tripp, SQLskills.com
Q: Can I view a recording of this webcast?Part 6 can be replayed by clicking here.
Q: Where can we get the demo scripts AND the sample database: Credit? The demo scripts are in this zip (20050916MSDNDemoScripts.zip (6.11 KB)); here in this blog entry. However, at the series completion, I will also create an entry under Past Event Resources for the entire webcast series. To download the ZIP of the Credit Database Backup click here. Once unzipped, restore this backup to SQL Server 2000 or SQL Server 2005. The backup is a SQL Server 2000 backup and can be restored to either version! If restoring to SQL Server 2005, you might want to change the destination for the data and log file as the path will probably be different.
Q: Where are the links to all prior Webcast Q&As from this series?
Q: How can I replay previous sessions? I thought we were going to get emails for replaying — but I haven't received any replay emails. You will receive replay emails ONLY when you register for these sessions through MSDN. We’ve come to find out that there are other ways to register but it’s only through MSDN that we know for sure you will receive the replay information.
Q: I know you have covered indexes and backups in other webcasts, but here is my question I use heavily temporary tables. My TempDB grows up to 5 GIG. Should I backup or truncate the transaction log in order to bring it back to its normal size? No, there is no need to specifically maintain the transaction log of the TempDB database. If the transaction log (and subsequently, the database) grows large – there could be multiple reasons for that and instead of thinking in terms of trying to manage the log, I’d look at long running transactions and/or large transaction. You can use Profiler to help you see long running and/or large transactions.
Q: Can I perform a database snapshot to another server? No, database snapshots must be created on the same server as the database on which the snapshot is being based.
Q: Can I snapshot by filegroup? No, however if what you want to do is create a snapshot which does NOT include certain files – you can take those filegroups offline and then create the snapshot. In the snapshot the only file/filegroups available will be those which were online when the snapshot was created…even if those files/filegroups are brought online after the snapshot was created.
Q: Could a reader be blocked on the snapshot DB while SQL updates the changed page? No. The copy on write mechanism is really a copy before write mechanism and the pages will be copied before the write and essentially before the locks, etc. The only possible “blocking” could be caused by the excess I/Os that need to be performed. However, the I/Os are performed only on the FIRST change to the page after the snapshot is created – so it’s minimal!!
Q: Are DMVs in SQL Server 2005 only?Yes, DMVs = Dynamic Management Views and these are a feature of SQL Server 2005.
Q: Is read uncommitted the lowest/least in terms of data consistency? Yes, read uncommitted is also known as “dirty read.” A dirty read is a read against an “in-flight” transaction; this transaction could be rolled back. As a result, the query that read that data would be inaccurate.
Q: What is the effect of versioning on fragmentation and performance (I'm assuming I create a split of the page is full)? Actually, I’m not sure I’m following this one… But – I think I can answer it by just giving you some insight into how things work. Versioning – in terms of the data overhead added to the data row – does add a 14 byte value to help store the offset. This overhead is added ONLY once, to each row, after one of the snapshot isolation options is turned on (either or both – the READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION). When this 14 byte value is added to each of the rows, the additional 14-bytes might cause the page to split. Again, this is only a one-time addition. The trick to optimizing this structural change is to change the database option and then rebuild your indexes. This will make the data contiguous and versioning will have no additional affects on the data row. Now, if what you were thinking is that the versions were stored in the data row – then this is NOT the case. The version store comes from the TempDB and as a result, there is no additional overhead (over the 14-bytes) needed within the data row.
Q: What if we're not using transactions? Will repeatable read still lock the table during the read (particularly if the select is long)? Repeatable reads locks – and holds – the resources as they are read. So, YES, in the case of a select statement, you will acquire and hold the read locks for the life of the transaction.
Q: How much additional overhead does versioning require from the SQL Server engine? Most of the overhead comes from TempDB but there’s also a bit of overhead in looking up the version. There are no direct numbers associated with the overhead but in a lot of cases you should think in terms of roughly 10% additional costs for your transaction… So, I guess the best point is that you will have slower overall performance when implementing row version; however, you might solve a lot of your blocking problems. Slower but not blocked is better than not running at all – even when it does run at all quickly. J In all seriousness though, if blocking is NOT your primary problem, you will add overhead without a possible benefit.
Q: So, is it the new transaction data or the old transaction data held in the snapshot store (seems like it might be different for statement vs. transaction level snapshotting)? It’s always the BEFORE image. The general process of the write is called “copy on write” but I think of it better as copy before write.
Q: Can we optimize the snapshot store (different physical device, file group(s), etc.)? No. However, you should look at optimizing TempDB. There are multiple things that you might want to consider. I discuss those thing in this blog entry here.
Q: If I don’t need locking why shouldn’t I use read-uncommitted? Hmm, you can… you just need to be aware of the fact that the data is “dirty” and is not guaranteed to persist.
Q: Where does SQL store all the row versions (with snapshot isolation turned on)? The version store is in TempDB.
Q: How do I view all of the Report options from the summary page? I am looking at Adventureworks (compatibility level = 90), but all that I see is the General report. Ah, ha! The new summary windows were added to after the beta II April CTP. So, what this tells me is that you’re running a build lower than 9.00.1187.07. At this point, I’d go for the September CTP which is build 9.001314.06.
Q: This question is from previous webcast… Is there anything new with SQL 2005 that does datetime support data types? Time datatype or Date datatype only? No, SQL Server 2005 only includes the datetime datatype for date/time data. However, by using “custom types” you can create your own types which are date only or time only (just for one example). There were separate SQLCLR types of date only and time only in SQL Server 2005; however these were non-native types and subsequently removed. Instead, they will be shipped as examples in a resource kit which ships after RTM.
Q: Kimberly, the downloadable zip file from your blog for at least the first session will only unzip to a "C:" drive (which my system doesn't have ;^) Could you please re-zip it to allow election of the drive to which it should unzip? This one still perplexes me. I didn’t set any options that would restrict this…
For the next session, we’re going to cover how SQL Server keeps plans, where you can look to see what's in cache AND how you can know better if the stored procedure's plan should be kept…or not? If you’re interested in hearing more – here’s the registration link:
See you on Friday!