Kalen Delaney : metadata

Did You Know? Turning Off Locking

Kalen Delaney — Mon, 07 May 2012 23:35:00 GMT

Back when the lock manager was rewritten for SQL Server 7, and row level locking was added to the product, the procedure sp_indexoption gave us the ability to turn OFF either row or page locks or both, for one particular index, or for a table and all...(read more)

Geek City: Plan Caching Internals

Kalen Delaney — Mon, 23 Aug 2010 17:04:00 GMT

This Friday is the last of my summer seminars. On August 27, I am presenting on plan caching, plan reuse and recompile and plan cache metadata. This is one of my favorite topics to talk about, because a lot of the information is not very widely known,...(read more)

Geek City: My Big Fat Partitioning Query

Kalen Delaney — Mon, 26 Jul 2010 15:45:00 GMT

When SQL Server first introduced table and index partitioning in SQL 2005, it was the same version that all the metadata changed. So I decided that I could learn a lot about metadata and a lot about the organization and storage of partitions if I tried...(read more)

Geek City: Exploring the Transaction Log Structure

Kalen Delaney — Tue, 22 Dec 2009 00:48:00 GMT

As I mentioned last October, my PASS preconference seminar was a whole day about the transaction log . I told the attendees all kinds of things about the structure of the log, and told them about one of the best tools for exploring the structure: the...(read more)

Geek City: How Many Rows?

Kalen Delaney — Mon, 07 Dec 2009 17:59:00 GMT

In my last post, I told you I'd post something technical before I left for Sweden. I almost made it. I wrote this in the Seattle airport, but wasn't able to post it until I got to Stockholm. For as long as I've been working with SQL Server, I've been...(read more)

Geek City: What do you intend with that lock?

Kalen Delaney — Fri, 11 Sep 2009 17:56:00 GMT

Way back in the olden days, prior to SQL Server 7, I already knew that the lock manager was one of the most complex and resource intensive parts of SQL Server. Keeping track of every lock held, who was waiting for that lock, who could be granted the lock,...(read more)

Geek City: ALTERing a Partition Function

Kalen Delaney — Sun, 16 Aug 2009 20:31:00 GMT

Finally, a real geeky post. I received two questions in as many weeks about what really happens to existing partitions when you alter the underlying partition function. The big question being… does altering a partition function cause any data movement?...(read more)

Geek City: Two Compression Questions and Parameter Metadata

Kalen Delaney — Tue, 10 Mar 2009 17:46:00 GMT

I am teaching the SQL 2008 version of my course for the first time this week. My life is still is disarray and spare time is practically non-existent. During the evenings after I class I am trying to get caught up on several projects that I fell way behind on over the last month when most of my time was spent in the hospital. Blogging has been put on the back burner, but I thought I could share some of the questions that came up in class on the first day. I usually try to track down answers to open questions, and then share them with the students the next day.

1. Why can't the stored procedure sp_estimate_data_compression_savings be available on SQL Server 2008 Standard Edition, instead of just Enterprise, Developer and Evaluation? We realize that compression is an Enterprise only feature, but if non-Enterprise users could see how much space they would save, it might help them determine whether Enterprise Edition is worth while?

(OK, here's a really geeky part... speaking of Enterprise, my #1 son sent me this link yesterday. )

Now I'm not saying that Microsoft should be obnoxious about this and say "See what you could save if you upgraded to Enterprise", and do that whether the user wants to know or not. It would be on request, when the user ran this procedure.

I also understand that the procedure actually applies compression to a sample of pages to compute the savings potential. And it was confirmed last night when I started researching this question that Enterprise features are just turned on and off through a switch so it actually would be easy enough to just not do the check for Enterprise Edition within this stored procedure. Microsoft is looking at possibly making this change, but it looks like it might not happen before the next major release.

2. Since page compression is applied on a page by page basis, what's the point of compressing a read-only table? Each page would be compressed, perhaps into a small amount of space, but if no new rows were added, the empty space on each page wouldn't get used and we would still have the same number of pages in the table.

Although it is true that compression is applied on each page individually, you need to rebuild the table or index in order to compress it, with ALTER TABLE or ALTER INDEX. And rebuilding a table or index moves the data to all new pages. So as the table is being rebuilt, when a page gets full, it is compressed, but then more rows can be added, and when are sufficient number are added, it gets recompressed, and keeps getting recompressed as more rows are added, until there is no chance of any more more rows being added. So during the rebuild process the table really isn't read-only, as the original data is being inserted into the a new copy of the table. You could end up with far few pages.

This is pretty easy to test out, by just compressing a relatively full table of your own into a test table (so no one will update it) and then compressing it. It should take less space.

There are lots of compression scripts, plus a lot more detail about how compression works, in my new book, which is scheduled for release TOMORROW!!

3. Where is the metadata that contains the default values of SQL Server stored procedure parameters?

Uh, the answer appears to be 'None of the above'. There is no metadata, either system views or system tables (viewable using the DAC) that contains this information.

You can read this Connect request for more details (and even vote for it if you like):

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=234143

It does seem strange that this information is not available and it's hard to believe SQL Server parses the procedure definition every time it wants to know the default. It turns out that even if all you want to know is whether or not a default exists is not easy to find. (You might want to know that to be able to determine if a parameter is optional.)

So now you know.

~Kalen

Geek City: Clearing a Single Plan From Cache in SQL Server 2008

Kalen Delaney — Fri, 31 Oct 2008 23:43:00 GMT

I just today found out about something that was in plain sight in the Books Online... but the documentation is so vast, I haven't discovered everything yet.

I blogged about clearing a single plan from cache in SQL Server 2005 a while back, and mentioned a rumor that there would be a new way to do this in SQL Server 2008. And then just today, someone posted a comment on that blog post, asking about the new 2008 method.

One of my contacts on the SQL Server team at Microsoft just sent me an email telling me about new features related to plan caching, as I am starting to work on updating that chapter for my 2008 book. He mentioned that DBCC now takes parameters, and one of the parameters is a plan handle!

DBCC FREEPROCCACHE [ ( { plan_handle | sql_handle | pool_name } ) ] [ WITH NO_INFOMSGS ]

There is full example in the Books Online, so I won't repeat it here. If you don't have a local copy of BOL handy, you can read about the new option to DBCC FREEPROCCACHE online here:

http://msdn.microsoft.com/en-us/library/ms174283.aspx

Have fun!

~Kalen

Geek City: Reducing Cache Bloat and a Metadata Bug

Kalen Delaney — Wed, 29 Oct 2008 23:43:00 GMT

I've been running some tests with the new SQL Server 2008 configuration option 'optimize for ad hoc workloads' which is intended to reduce cache bloat due to holding onto plans for single use ad hoc queries. This option will allow a new type of cached object to be stored, which isn't the only plan, but merely a stub. There will be a corresponding new cacheobjtype value called "Compiled Plan Stub".

There are several ways of looking at the contents of cache. In SQL 2000, we had a pseudo table called master.dbo.syscacheobjects, and we can still access this object in SQL 2005 and 2008 by referencing the compatibility view sys.syscacheobjects (from any database). However, when I look at this view, I don't see "Compiled Plan Stub", but rather "Compiled Plan Stu ".

So I checked the definition of syscacheobjects, using the function object_definition:

USE master;
SELECT OBJECT_DEFINITION(object_id('syscacheobjects'));

and I saw that syscacheobjects was derived from a column in sys.dm_exec_cached_plans, and converted to an nvarchar(17). Unfortunately, "Compiled Plan Stub" is 18 characters long.

I'll be talking about this new cached object type in my 3-day seminar in London next week, and I'll post more information about using the 'optimize for ad hoc workloads' at a later time.

But normally, I wouldn't have run into this problem, because I have created my own view based on the new SQL 2005 metadata, including sys.dm_exec_cached_plans. Usually, I use my own view, which converts to a longer string, so I wouldn't have seen the string truncation. But I was testing this on a new instance, where I hadn't created my own view yet.

I am including my view definition, which is what I have been using since the SQL Server 2005 came out, to inspect the plan cache. In fact, I usually add a where clause to restrict the output only to Compiled Plans. Note that the view name starting with sp_ means we can access the view from any database:

-- Create a view to show most of the same information as
--   SQL Server 2000's syscacheobjects
USE master
GO
CREATE VIEW sp_cacheobjects(bucketid, cacheobjtype, objtype, objid, dbid, dbidexec,
             uid, refcounts, usecounts, pagesused, setopts, langid, dateformat, status, lasttime,
             maxexectime, avgexectime, lastreads,lastwrites, sqlbytes, sql)
AS
SELECT
    pvt.bucketid,
    CONVERT(nvarchar(20), pvt.cacheobjtype) as cacheobjtype, pvt.objtype,
    CONVERT(int, pvt.objectid)as object_id, CONVERT(smallint, pvt.dbid) as dbid,
    CONVERT(smallint, pvt.dbid_execute) as execute_dbid,
    CONVERT(smallint, pvt.user_id) as user_id, pvt.refcounts, pvt.usecounts,
    pvt.size_in_bytes / 8192 as size_in_bytes,
    CONVERT(int, pvt.set_options) as setopts, CONVERT(smallint, pvt.language_id) as langid,
    CONVERT(smallint, pvt.date_format) as date_format, CONVERT(int, pvt.status) as status,
    CONVERT(bigint, 0), CONVERT(bigint, 0), CONVERT(bigint, 0), CONVERT(bigint, 0),
    CONVERT(bigint, 0),CONVERT(int, LEN(CONVERT(nvarchar(max), fgs.text)) * 2),
    CONVERT(nvarchar(3900), fgs.text)

    FROM (SELECT ecp.*, epa.attribute, epa.value
               FROM sys.dm_exec_cached_plans ecp
                    OUTER APPLY sys.dm_exec_plan_attributes(ecp.plan_handle) epa) as ecpa
               PIVOT (MAX(ecpa.value) for ecpa.attribute
                   IN ("set_options", "objectid", "dbid", "dbid_execute",
                       "user_id", "language_id", "date_format", "status")) as pvt
                OUTER APPLY sys.dm_exec_sql_text(pvt.plan_handle) fgs

This view shows the full cached object type:

Have fun!

~Kalen

Did You Know: How Compatible are the Compatibility Views?

Kalen Delaney — Mon, 15 Sep 2008 01:51:00 GMT

You're probably aware that the metadata interface changed completely in SQL Server 2005, and we no longer have direct access to the system tables. Instead, Microsoft provided us with two sets of views: the catalog views and the compatibility views.

The catalog views are the preferred interface going forward, as they are fully documented and the naming conventions are much more user friendly. There are also no bitstrings, like the status fields that need to be decoded. Each attribute stored in the view is available in a separate column.

The compatibility views are there to let you use the same code that you used in SQL Server 2000, hopefully temporarily, while you convert your code to the new metadata using the catalog views. The compatibility views have the same names as the system tables in SQL Server 2000, and the column names are the same.

You might think that writing a query against the compatibility views would then allow you to continue to write metadata queries that work with either SQL 2000 or SQL 2005. This might be true to some extent, but we might have to define what we mean by 'work'. Another change that happened in SQL 2005 was the separation of users and schemas. Users can have permissions granted to them, including permissions to create objects, but the objects exist in containers called schemas.

In SQL 2000, users and schemas are treated interchangeably. If you create a user sue, SQL Server automatically creates a schema sue which is the user sue's default schema. When the user sue selects from an unqualified object t1, SQL Server 2000 assumes she is selecting from an object sue.t1. (If there is no object sue.t1, SQL Server then looks for dbo.t1.)

In SQL 2005, a user sue can have any schema as her default schema and there may or may not be a schema named sue. When accessing an object that is not in your default schema or in the dbo schema, you must qualify the object with the schema name, not the owner name.

So what's my point here?

If you're looking up information about objects in aSQL 2005 database, would you rather know the owner of your objects or the schema they are contained in? I suggest that it is more often the case that you want to know the schema, so that you can then access the objects you are exploring. And here's where the incompatibility of the compatibility views comes in.

In SQL 2000, the following code will give you the owner and name of all your user tables, and you can then use the information returned to access the objects. I wrote this query this morning in answer to a newsgroup posting asking for information about getting owner and object information from both SQL 2000 and 2005.

SELECT u.name as [user],
       o.NAME as [object]
FROM sysobjects o
         INNER JOIN sysusers u
           ON o.uid = u.uid
WHERE   type = 'U';

In SQL 2005, the same code will give you the owner name, but that is NOT the name needed to access the objects. Here's an example that uses a test database, and creates a login sue, a user sue, and a schema called sue_schema. The user sue is given permission to create tables and to alter the sue_schema schema. The user sue then creates a table called sue_table.

USE testdb;
GO
CREATE LOGIN sue
WITH PASSWORD = 'sue_password';
CREATE USER sue FOR LOGIN sue;
GO
CREATE SCHEMA sue_schema;
GO
GRANT CREATE TABLE TO sue;
GO
GRANT ALTER ON schema::sue_schema TO sue;
GO
EXECUTE AS user='sue';
GO
CREATE TABLE sue_schema.sue_table (a int);

We can run the metadata query above, and add a filter to look for sue-type objects:

SELECT u.name as [user],
       o.name as [object]
FROM sysobjects o
         INNER JOIN sysusers u
           ON o.uid = u.uid
WHERE   type = 'U' AND o.name like '%sue%';

I get these results:

user object
------- ---------
sue sue_table

However, for table access, this information is not helpful. I cannot execute the following statement, even as dbo with full privileges:

REVERT; -- so I no longer execute as user 'sue'
SELECT * FROM sue.sue_table;

So is the metadata query really compatible? It may be compatible in the facts it gives back, but in function, it is not. For SQL Server 2005, the query does not tell us what we need to know in order to access object. Instead, we'll need a catalog view sys.schemas, which has no equivalent in SQL 2000.

SELECT s.name as [user],
       o.name as [object]
FROM sysobjects o
         INNER JOIN sys.schemas s
           ON o.uid = s.schema_id
WHERE   type = 'U' AND o.name like '%sue%';

So because of the split between users and schemas, we can't really write one query that gives us information about how to access objects in both SQL 2000 and SQL 2005.

~Kalen

Geek City: System Objects

Kalen Delaney — Mon, 11 Aug 2008 05:11:00 GMT

As you might know, metadata is one of my favorite topics, and I've written quite a bit about metadata and system objects. A very frequent question is: What exactly IS a system object?

There are quite a few different definitions you could use. You could say a system object is one that was installed with your SQL Server installation.

You could say it is one that starts with a special prefix, like 'sys' for objects if you're using SQL Server 2000 or earlier, or one in the sys schema if you're using SQL Server 2005.

You could say a system object is one that has an object id of less than 100.

In the old SQL 2000 Enterprise Manager, you could look at a list of objects in a database, and there was a column called 'type' with a value of either 'system' or 'user'.

The objectproperty function has an argument called 'IsSystemTable', that will show you which tables are system tables, but won't do anything for other system objects.

The objectproperty function also has an argument called 'IsMSShipped', which corresponds to a column in the SQL 2005 metadata view sys.objects called 'is_ms_shipped'.

SELECT *
FROM sys.objects
WHERE OBJECTPROPERTY(object_id, 'IsMSShipped') = 1;

But just because something is shipped by Microsoft, is it really a system object? There is an undocumented procedure called sp_MS_marksystemobject, that would change the properties of any object you created so that its 'is_ms_shipped' property would also show a value of 1. Does that make it a system object, just because you marked it as such?

CREATE TABLE tiny
(col1 int);
GO
EXEC sp_MS_marksystemobject 'tiny';
GO
SELECT *
FROM sys.objects
WHERE OBJECTPROPERTY(object_id, 'IsMSShipped') = 1;

I usually think of system objects as ones that have special behavior. Procedures in the master database, that start with sp_ are special, in that you can access them from anywhere. It turns out that you can create views and tables in master, with names starting with sp_, and they will also be accessible from any database, without fully qualifying the name.

System tables have always had special behavior, in that you couldn't update them without setting a configuration option for the whole server. Once you set 'allow updates' to 1, you could update system tables, in versions before SQL 2005. Metadata changed completely in SQL 2005, and I thought for a long time that the 'allow updates' configuration option didn't do anything anymore. But I just recently found out that is not true. There is something special that 'allow updates' allows.

If you run the following, you will be given an error message:

sp_configure 'allow updates', 1;
reconfigure;

Configuration option 'allow updates' changed from 0 to 1. Run the RECONFIGURE statement to install.
Msg 5808, Level 16, State 1, Line 2
Ad hoc update to system catalogs is not supported.

So it tells you to RECONFIGURE, but when you do, you still get an error. However, if you run RECONFIGURE WITH OVERRIDE, you get no error:

sp_configure 'allow updates', 1;
reconfigure with override;

It turns out that you if you set 'allow updates' to 1, any procedure that you create in the master database will automatically be marked as 'is_ms_shipped'. You can observe this either with the OBJECTPROPERTY function or the is_ms_shipped column in sys.objects. This doesn't seem to work for tables or views, and it doesn't give the procedure any special behavior, but it changes a internal status bit to make the object seem like something special.

USE master;
GO
CREATE PROC today
AS SELECT getdate();
GO
SELECT *
FROM sys.objects
WHERE is_ms_shipped = 1 AND name LIKE 't%';

Have fun!

~Kalen

Geek City: Why I still need Sysprocesses

Kalen Delaney — Mon, 30 Jun 2008 03:48:00 GMT

I've said many times that my favorite new feature in SQL Server 2005 is the new metadata, in particular the new Dynamic Management Objects. When I have to do troubleshooting on a SQL Server 2000 system, it is worse than painful, not to have my favorite tools like sys.dm_tran_locks, sys.dm_exec_cached_plans and
sys.dm_exec_query_plan. By now, on the eve of the release of the version AFTER SQL Server 2005, my transition to the new metadata is almost complete.

With one notable exception...

I have always used sysprocesses constantly for troubleshooting information. Although most of the useful information that allows me to see what sessions are using lots of memory, or performing lots of I/O, can found in sys.dm_exec_sessions, there is one piece of information that isn't there. Sysprocesses contains a columns called open_tran which reflects the transaction nesting of each session. If a session issues four BEGIN TRAN commands, with no COMMITs or ROLLBACKs, their session will have an open_tran value in sysprocesses of 4. Any open_tran value greater than 0 might mean that a transaction is holding locks and blocking other processes, or it might be keeping the transaction log from being cleared. If you ever notice open_tran values in higher than 2 or 3, it's a pretty good indication that a developer doesn't know much about SQL Server transaction management. I use this value all the time, and once had to troubleshoot a system where dozens of connections had open_tran values in the 20s and 30s! (For more details about nesting transactions, see my earlier post.

So imagine my surprise when I discovered that the sys.dm_exec_sessions view, which is supposed to 'replace' sysprocesses in SQL Server 2005, has no column to provide this information! Another view, sys.dm_exec_requests, has a column called open_transaction_count, which you might think would be the same thing. And it actually is the same information, but the sys.dm_exec_requests view only returns rows for sessions that are currently active, i.e. currently running a query. The need for examining the open_tran value is greatest when looking at those sessions that aren't doing anything, but are just sitting there with an open transaction. Those are the processes that you need to troubleshoot. I had felt that the omission of open_tran (or open_transaction_count) from sys.dm_exec_sessions was just an oversight, and it would be 'fixed' in the next release. But it appears I am to be disappointed. I just checked sys.dm_exec_sessions in RC0, and there is still no open_transaction_count column.

So long live sysprocesses!

~Kalen

Geek City: What's Worse Than a Table Scan?

Kalen Delaney — Sun, 25 May 2008 20:59:00 GMT

I have frequently heard SQL Server developers and DBAs gasp when a query plan is indicating that SQL Server is performing a table scan, thinking that is the worst thing that could ever happen to a query. The truth is, it's far from the worst thing and in addition, not all table scans are created equal.

One thing that is far worse that a table scan is to execute a query plan that uses a nonclustered index, and having that plan look up every single row in a table! Although that is a horrible thing to behold, it is not the topic of this post.

Today, I'm going to show you that two different table scans on the same data in a heap can give very different performance.

The behavior has to do with a technique that SQL Server uses when a row in a heap is increased in size so it no longer fits in the original page. This usually occurs when a variable length column is updated to take more space. If SQL Server just moved the row to another page, any nonclustered indexes would have to be updated to indicate the new page address. (Remember, if the underlying table is a heap, nonclustered indexes point to the data row using a actual address.) Since there can be up to 249 nonclustered indexes on a single table, that could potentially be a LOT of work. So instead, when a row in a heap has to move, SQL Server leaves behind a forwarding pointer in place of the row that has moved. The nonclustered indexes continue to point to the old location, and then SQL Server just needs one more page lookup to find the new location. For just a few lookups, this expense is minimal and more than made up for my the savings of not having to update all the nonclustered indexes every time a row moves.

However, what happens when there are LOTS of forwarding pointers?

The metadata function sys.dm_db_index_physical_stats has a column that indicates how many forwarded records are in any table. For tables with clustered indexes, this will always be 0.

Let's look at an example. I'll make a copy of the Person.Address table in the AdventureWorks database, and add a new varchar column to it. Initially, the column takes no space.

USE AdventureWorks;
GO
IF EXISTS (SELECT 1 FROM sys.tables
            WHERE name = 'Address2' AND schema_id =1)
        DROP TABLE dbo.Address2;
GO
SELECT *, convert (varchar(500), 'comments') AS comments
   INTO Address2
FROM Person.Address;
GO
-- note that the pages are almost full and there are no forwarded records
SELECT index_type_desc, page_count, avg_page_space_used_in_percent,
     avg_record_size_in_bytes,forwarded_record_count
FROM sys.dm_db_index_physical_stats(db_id('AdventureWorks'),
       object_id('Address2'),null, null, 'detailed');
GO

Now I'll increase the length of all the new columns and check the physical stats again:

UPDATE Address2
SET comments = replicate('a', 500);
GO
SELECT index_type_desc, page_count, avg_page_space_used_in_percent,
avg_record_size_in_bytes,forwarded_record_count
FROM sys.dm_db_index_physical_stats(db_id('AdventureWorks'),
object_id('Address2'),null, null, 'detailed');
GO

The output shows me I have 1763 pages in the table and 15961 forwarded records.

Let's see what happens when we read every row in the table:

SET STATISTICS IO ON;
SELECT * FROM Address2;
SET STATISTICS IO OFF;

The logical I/O value tells us that instead of just reading through every page, for a total of 1763 reads, SQL Server jumps out of sequence and follows the forwarding pointer for every forwarded record. So the number of logical reads is the sum of the number of pages plus the number of forwarded records:

1763 + 15961= 17724

I was discussing this behavior with my friend and colleague Tibor Karaszi and he proposed an explanation for this behavior. He related it to the same behavior that Itzik Ben-Gan has described for why SQL Server will always follow page pointers when scanning a clustered index if consistent reads are desired. The alternative would be to just read the pages in disk order, or page number order, which can be determined by examining the IAM structures for the object. For clustered tables, we need to follow the page pointers instead of the IAMs to make sure that if a row is moved due to an update while the scan is occurring, that we don't read the same row twice (if the row is moved to a higher page number) or skip the row altogether (if the row is moved to a lower page number.)

But what about a heap? Are there potential problems scanning a heap while updates are occurring? Could we potentially read the same row twice or skip a row, since there is no 'ordered list' to read? Tibor suggested the following:

I believe that forwarding pointers take care of just that. Because of forwarding pointers, the "root" location for a row is stable. So, even if the row moves during a scan, the "root location"(forwarding stub) is at the same position. We have concluded that the scan uses the forwarding pointers when reading the rows. This means that a scan is not sensitive to row movements during the scan. It cannot "skip" rows that are there, or read the same row twice.

So a few forwarding pointers are not a bad thing, but having lots of them can increase the work done during scans or partial scans by a considerable amount.

So how do you get rid of forwarding pointers? There are 3 ways:

1. If the row is updated, so that its size decreases, AND if there is still room on the page where the row came from, it will be moved back. This is not dependable, so it isn't really recommended as a solution. When I updated my Address2 table, many of the forwarded records were moved, but not all:

UPDATE Address2
SET comments = '';
GO
SELECT index_type_desc, page_count, avg_page_space_used_in_percent,
avg_record_size_in_bytes,forwarded_record_count
FROM sys.dm_db_index_physical_stats(db_id('AdventureWorks'),
object_id('Address2'),null, null, 'detailed');
GO

My results showed that I am still left with 1080 forwarded records. This is a great improvement over 15961, but it's still more forwarded records than there are pages in the table.

2. Forwarded records will be cleaned up when you shrink the data file. This is definitely NOT recommended as a solution; I am only mentioning it for completeness. SQL Server does so much moving of data and updating nonclustered index pointers when shrinking a file, that updating the forwarded records is not very much extra work at all.

3. Since forwarded records only exist in heaps, the best solution is to make the table not a heap. Build a clustered index, and all the forwarded records will go away. If you really don't want the clustered index, you can then drop it.

Hopefully, this information will be useful to you.

~Kalen

Did You Know? My DVD is in Production!

Kalen Delaney — Fri, 08 Feb 2008 22:15:00 GMT

The editing for Lesson 1 is done and the production run of my DVD has started. We're expecting shipping to start in about 2 weeks.

In addition, we've extended the pre-order price for another 5 days, so any orders that come in before Valentine's Day will get the special reduced price.

Because this is taking a bit longer than we hoped, we are going to make the edited DVD available online. If you've pre-ordered, you'll be able to view the online version for free. I'll post the URL as soon as it's ready.

For now, check out http://DVD.KalenDelaney.com

Thanks!

~Kalen

P.S. Lesson 2 has already been recorded, and is now being edited.