Ok, so I lied. I said next time we'd look at key and certificate based catalog views. But, quite frankly, they're intensely boring and my brain started to wander. So, I thought I'd just skip that chapter, and talk about the storage catalog views instead. Much better.
So, we're talking about filegroups, partition functions and partition schemes... The views we're interested in are [sys].[data_spaces], [sys].[filegroups], [sys].[partition_schemes] and [sys].[destination_data_spaces].
Let's look at [sys].[data_spaces] first:
name | The name of the data space, which must be unique. Rocket science factor = 0. |
|---|---|
data_space_id | The unique ID of the data space, used everywhere that metadata has to reference a data space (for example, index metadata, partition scheme destinations etc). |
type | This is the type code of the data space, one of the following:
|
type_desc | This is the description that relates to the value in the type column. |
is_default | This is 1 if the data space is the default, and is therefore used for tables and indices. To set a filegroup as the default, you can use the ALTER DATABASE [name] MODIFY FILEGROUP [name] DEFAULT. Note that although the documentation talks about default data spaces, partition functions cannot be default data spaces, because they require the use of a partition function. In the future, there may be other types of data space which can be default, however. |
So we get a basic overview of data spaces with that view. For some more specifics, we need to delve deeper. Looking at [sys].[filegroups] tells us more about filegroups. Like the schema-scoped object catalog views, we inherit columns from [sys].[data_spaces], and the extra columns we get are:
filegroup_guid | The name of the data space, which must be unique. Rocket science factor = 0. |
|---|---|
log_filegroup_id | A wholly and completely useless column. I think they kept this one in there just to remind us of how bad the pre-2005 metadata tables were. |
is_read_only | This is 1 if the filegroup is read-only. This is effected using ALTER DATABASE [name] MODIFY FILEGROUP [name] READONLY. |
Not really much extra there, but what more do you need to know about filegroups? Oh... you wanted to know where the files actually are? [sys].[database_files] is your friend, but we'll cover that another time. Next on our journey this time is [sys].[partition_schemes]. Again, inheriting from [sys].[data_spaces], the extra columns we get are:
function_id | This is the ID of the partition function that determines on what boundaries data on the partition scheme. |
|---|
Was that it? How do we tell what filegroups the partition scheme points to? [sys].[destination_data_spaces] holds the answer.
partition_scheme_id | This column is an interesting choice of name, because it's actually a data_space_id. I guess they felt the name reinforces the fact that it relates to partition scheme data spaces only. |
|---|---|
destination_id | This is the ordinal of the destination. So, for a partition scheme with 12 partitions, you'll have 12 rows, with destination_id values from 1 to 12. |
data_space_id | This column again is interestingly named. It represents the data space to which data for the partition is sent. However, given that it's name is the same as the column in [sys].[data_spaces] that you're trying to relate to, you could be forgiven for thinking that this column stored the partition scheme's data_space_id. I would have preferred a column name of destination_data_space_id which would have clarified the column's meaning, and kept it in the same style as the table name. |
Ok, useful, if annoyingly named.
We now have all the information we need about storage - but we have a gap in terms of what the partition functions themselves actually do... Next time!