можноли индексы вынести в др. фаловую группу или файл?

Сергей84
Дата: 11.09.2006 16:54:27
предположи есть БД
есть куча индексов - скажем 100
так вот хочется разделить индексы и файлы по разным фалом, а может и по разным фаловым группам (в данном случае - главное отдельно от данных)
есть ли такая возможность без пересоздания индекса?
в BOL смотрел later table, но чаво-та не нашел :(
так же еще вапрос, если индекс кластерный, то данные таблицы и кластерного индекса нельзя разделить на разные фалы. правильно? (читал Мамаева - там написано так, читал BOL и на скока смог перевести - тоже самое, а спрашиваю - чтоб уж савсем не сомневаться, т.к. когда читаешь книги по разным СУБД можно чава-нибудь напутать)
P.S. просьба сильно не пинать :)
MsDatabaseru
Дата: 11.09.2006 17:19:58
BOL: Placing Indexes on Filegroups

By default, indexes are created on the same filegroup as the base table on which the index is created. However, it is possible to create nonclustered indexes on a filegroup other than the filegroup of the base table. By creating the index on a different filegroup, you can realize performance gains if the filegroups make use of different physical drives with their own controllers. Data and index information can then be read in parallel by multiple disk heads. For example if Table_A on filegroup f1 and Index_A on filegroup f2 are both being used by the same query, performance gains can be achieved because both filegroups are being fully used with no contention. However, if Table_A is scanned by the query but Index_A is not referenced, only filegroup f1 is used, resulting in no performance gain.

Because you cannot predict what type of access will take place and when it will take place, it could be a safer decision to spread your tables and indexes across all filegroups. This would guarantee that all disks are being accessed since all data and indexes are spread evenly across all disks, no matter which way the data is accessed. This is also a simpler approach for system administrators.

If there is a clustered index on a table, the data and the clustered index always reside in the same filegroup. Therefore, you can move a table from one filegroup to another by creating a clustered index on the base table that specifies a different filegroup on which to create the index (the index can then be dropped, leaving the base table in the new filegroup).
Сергей84
Дата: 12.09.2006 09:42:02
если в filegroup входит 2 файла, то может ли таблица находиться в 1-м файле, а кластерный индекс во втором?
Glory
Дата: 12.09.2006 09:59:34
Сергей84
если в filegroup входит 2 файла, то может ли таблица находиться в 1-м файле, а кластерный индекс во втором?

Нет, данные распределяются равномерно между файлами в одной группе
Сергей84
Дата: 12.09.2006 12:18:29
всем, кто откликнулся спасибо, но я пока так и не понял, как можно уже созданные индексы перенести в др. файловую группу, кроме как удалить их и создать занова - это уж больно утомительная процедура
есть ли для этого готовое средство
или
может можно написать его самому например написать курсор, который бы все найденные индексы удалял, но при этом в нем можно было бы найти текст индекса (например поможет ли функция sp_helptext), который бы можно было динамически изменить и создать индекс с новыми параметрами (такими как др. фаловая группа)
может это уже кто-нибудь делал?
Сергей84
Дата: 13.09.2006 09:13:15
up
tpg
Дата: 13.09.2006 09:14:52
sp_helpindex
Сергей84
Дата: 13.09.2006 09:23:24
2 tpg - спасибо

2 all
возник еще один вопросик, и чтобы не плодить ветки спрошу здесь
имеем БД MSSQL 2000 на диске у которого размер кластера 4 kb, изменится ли производительность работы MSSQL 2000 по работе с дисковой системой, если кластер сделать равным странице, т.е. 8 kb? и если да то в какую сторону и приблизительно на скока?
-=DiM@n=-
Дата: 13.09.2006 09:31:35
Ну вообще-то сервер выделяет память экстентами по 8 страниц, т.е. по 64Кб. Так что уж если делать размер кластера, то равным 64Кб. Хотя толка от этого не много будет.
Сергей84
Дата: 13.09.2006 15:39:55
up
будут ли еще мнения?
вопрос возник, т.к. по словам Progress DBA, при увеличении размера кластера до 8кб, Progress, который работает блоками по 8кб - стал работать быстрее