Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ballista, Вы писали:
B>>в плане ничего не увидишь. проблема в том, что без FK сервер может применять многоблочную запись, контроллер может применять read ahead, а с FK скорость бывает и в 10 раз падает, потому что сервер вынужден читать по блочно, на один блок таблицы, N блоков FK таблицы/индекса, гоняя головки HDD, вымывая кеши контроллеров.
S>Ну, если не в плане, то в статистике запроса мы должны это увидеть.
S>Где посмотреть на пример? Чтобы прямо было видно как cache miss возрастает, и как контроллер при записи перестаёт применять read ahead.

лично я смотрел сырые оракловые трейсы, пытаясь понять откуда 8 раз разница. мне кажется майкрософт в принципе нигде не показывает применяет ли мсскл многоблочное чтение или читает лишь один блок. т.е. вы вообще ничего не увидите на уровне мсскл. плюс я говорил о вымывании кешах контроллера, думаю в большинстве случаев это вообще не посмотреть.
но суть не в этом, суть в том что люди, которых в невежестве не заподозрить проблематично открыто советуют дизейблить FK при загрузке. Например Kimball тут советует http://www.essai.rnu.tn/Ebook/Informatique/The%20Data%20Warehouse%20Toolkit,%203rd%20Edition.pdf

еще тут конкретно в связке с мсскл

Jeff Smith on Tue Oct 12, 2010 10:16 am
Defining the foreign keys on the fact table is supposed to help the star schema optimizer in SQL Server 2008. Without the constraints, the optimizer decides on it's own which table is the fact table and which is a dimension table.

If you define the foreign keys, turn off the referential integrity otherwise it will bring your load to a standstill.

Some say that you should turn the referential integrity back on after the load to prevent developers from doing something they shouldn't do with the dimension tables. Some say leave it off. Personally, turn the referential integrity on between loads — the added protection doesn't hurt.

http://kimballgroup.forumotion.net/t765-foreign-key-constraints

т.е. такие "трюки" применят именно профи, которые глубоко в теме.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ballista, Вы писали:
B>>в плане ничего не увидишь. проблема в том, что без FK сервер может применять многоблочную запись, контроллер может применять read ahead, а с FK скорость бывает и в 10 раз падает, потому что сервер вынужден читать по блочно, на один блок таблицы, N блоков FK таблицы/индекса, гоняя головки HDD, вымывая кеши контроллеров.
S>Ну, если не в плане, то в статистике запроса мы должны это увидеть.
S>Где посмотреть на пример? Чтобы прямо было видно как cache miss возрастает, и как контроллер при записи перестаёт применять read ahead.

лично я смотрел сырые оракловые трейсы, пытаясь понять откуда 8 раз разница. мне кажется майкрософт в принципе нигде не показывает применяет ли мсскл многоблочное чтение или читает лишь один блок. т.е. вы вообще ничего не увидите на уровне мсскл. плюс я говорил о вымывании в кешах контроллера, думаю в большинстве случаев это вообще не посмотреть.
но суть не в этом, суть в том что люди, которых в невежестве не заподозрить открыто советуют дизейблить FK при загрузке. Например Kimball тут советует http://www.essai.rnu.tn/Ebook/Informatique/The%20Data%20Warehouse%20Toolkit,%203rd%20Edition.pdf

еще тут конкретно в связке с мсскл

Jeff Smith on Tue Oct 12, 2010 10:16 am
Defining the foreign keys on the fact table is supposed to help the star schema optimizer in SQL Server 2008. Without the constraints, the optimizer decides on it's own which table is the fact table and which is a dimension table.

If you define the foreign keys, turn off the referential integrity otherwise it will bring your load to a standstill.

Some say that you should turn the referential integrity back on after the load to prevent developers from doing something they shouldn't do with the dimension tables. Some say leave it off. Personally, turn the referential integrity on between loads — the added protection doesn't hurt.

http://kimballgroup.forumotion.net/t765-foreign-key-constraints

т.е. такие "трюки" применят именно профи, которые глубоко в теме.