web-dev-qa-db-ja.com

指定したファイルグループに新しいインデックス/テーブルが作成されないのはなぜですか?

@@ Versionからの結果

Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) 
Sep 21 2011 22:45:45 
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

これがデータベース定義です

CREATE DATABASE [Scratch] ON  PRIMARY 
( NAME = N'Scratch_mdf', FILENAME = N'N:\MSSQL\TEST\Primary\Scratch_mdf.mdf' , SIZE = 17664KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [DATA]  DEFAULT 
( NAME = N'Scratch_dat1a', FILENAME = N'N:\MSSQL\TEST\Data\Scratch_dat1a.ndf' , SIZE = 14539584KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_dat1b', FILENAME = N'N:\MSSQL\TEST\Data\Scratch_dat1b.ndf' , SIZE = 12016128KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [INDEX] 
( NAME = N'Scratch_idx1', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx1.ndf' , SIZE = 92864KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx2', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx2.ndf' , SIZE = 84416KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx3', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx3.ndf' , SIZE = 84416KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx4', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx4.ndf' , SIZE = 92864KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [PM_G0] 
( NAME = N'PM_data0', FILENAME = N'N:\MSSQL\PDB1\Data\PM_data0.ndf' , SIZE = 768000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%)
 LOG ON 
( NAME = N'Scratch_log1', FILENAME = N'N:\MSSQL\TEST\Log\Scratch_log1.ldf' , SIZE = 833024KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%) 
GO

ALTER DATABASE [Scratch] SET COMPATIBILITY_LEVEL = 100
GO

次に、テーブルを作成し、クラスター化インデックスを追加するコードを示します。どちらの場合も、ファイルグループPM_G0を指定していますが、ファイルグループDATAでチェックしています。

CREATE TABLE Scratch.dbo.STUPID_TEST (dummycol int) ON [PM_G0];
CREATE CLUSTERED INDEX ix_test ON stupid_test(dummycol) ON PM_G0; 
-- Tried the filegroup name with/without brackets just in case

次のクエリを使用して、最初のヒープ、次にクラスター化インデックスの場所を確認しています。

SELECT o.name objectname, fg.name filegroupname, sdf.name as datafile,i.name indexname, partition_id, partition_number, [rows]
FROM sys.partitions p
INNER JOIN sys.objects o ON o.object_id=p.object_id
INNER JOIN sys.tables t ON o.object_id = t.object_id
INNER JOIN sys.indexes i ON i.object_id=p.object_id and p.index_id=i.index_id
INNER JOIN sys.filegroups fg ON fg.data_space_id = i.data_space_id
INNER JOIN sys.database_files sdf ON sdf.data_space_id=fg.data_space_id
WHERE o.name = 'STUPID_TEST'

興味深いテスト。デフォルトのファイルグループを[index]に変更しました。 [インデックス]が実際にsys.filegroupsのデフォルトインデックスであることを確認してから、クラスター化インデックスを削除して再作成しましたが、それでも[DATA]ファイルグループに移動しました。以下のコード

ALTER DATABASE Scratch MODIFY FILEGROUP [index] DEFAULT;
GO
DROP INDEX dbo.STUPID_TEST.IX_test;
CREATE CLUSTERED INDEX ix_test ON stupid_test(dummycol) ON [PM_G0];
GO
4
Kenneth Fisher

まず、こちらとTwitterで私を助けてくれたすべての人に感謝します。しかし、最終的には答えを見つけました。誰かがモデルにデータベーストリガーを作成したことがわかりました。トリガーは、すべてのcreate index/tableコマンドを解析し、それがヒープまたはクラスター化インデックスである場合はDATAファイルグループに変更し、それ以外の場合はINDEXファイルグループに変更します。その後、トリガーを追跡してポリシーに戻すことができました。

3
Kenneth Fisher