Добавлено: Ср Июл 06, 2011 2:14 pm Заголовок сообщения: QUOTED IDENTIFIER и FILTERED INDEX
Есть в Акценте такие чудесные таблички: AG_PARAMS, JRN_PARAMS, DOC_PARAMS, в которые удобно кидать всякие малонужные данные. При чем таблички эти очень разреженные по той простой причине, что если установлен параметр одного типа, то остальные 4 отдыхают в null.
Появилось у меня нездоровое желание сделать для колонок с данными параметров индекс с фильтром. Но не все так просто... Оказывается, в Акцентовской базе опция QUOTED IDENTIFIER = off по умолчанию, да и так она обычно выключена, что в общем-то расходится с "умолчанием" мелкософта. А если QUOTED IDENTIFIER = off, то:
Цитата:
SET QUOTED_IDENTIFIER must be ON when you are creating or changing indexes on computed columns or indexed views. If SET QUOTED_IDENTIFIER is OFF, CREATE, UPDATE, INSERT, and DELETE statements on tables with indexes on computed columns or indexed views will fail. For more information about required SET option settings with indexed views and indexes on computed columns, see "Considerations When You Use the SET Statements" in SET (Transact-SQL).
Возникает вопрос: а можно ли его переключить в ON? Или где-то это может вылезти? Таблиц и колонок с "неправильными" названиями я в Акценте не помню, но случаи оно разные бывают... И не устанавливается ли он самим Акцентом?
P.S. Вопрос не праздный, т.к. есть определенные ситуации, когда приходится джоинить на параметры по несколько раз (бывает даже десятка два раз), а таблицы параметров и индексы довольно толстые (по несколько десятков мб).
Добавлено: Чт Июл 07, 2011 9:20 am Заголовок сообщения: Re: QUOTED IDENTIFIER и FILTERED INDEX
kris писал(а):
Возникает вопрос: а можно ли его переключить в ON? Или где-то это может вылезти? Таблиц и колонок с "неправильными" названиями я в Акценте не помню, но случаи оно разные бывают... И не устанавливается ли он самим Акцентом?
А можно уточнить, в этих табличках есть computed columns? Или это не таблички, а вьюхи, да еще и индексированные? Насколько я понимаю, данная настройка никак не изменит поведение системы.
Добавлено: Пт Июл 08, 2011 11:06 am Заголовок сообщения:
Индекс с фильтром сиквелом воспринимается как computed column.
Убираешь фильтр - все работает. Ставишь фильтр - любой insert, update, delete не проходит. Акцент выдает либо "информация об ошибке недоступна", либо ошибку, которую возвращает сиквел (точно воспроизвести не могу, т.к. не помню, надо моделировать, но смысл типа "insert/update/delete failed due to...")
Индекс с фильтром сиквелом воспринимается как computed column.
Убираешь фильтр - все работает. Ставишь фильтр - любой insert, update, delete не проходит. Акцент выдает либо "информация об ошибке недоступна", либо ошибку, которую возвращает сиквел (точно воспроизвести не могу, т.к. не помню, надо моделировать, но смысл типа "insert/update/delete failed due to...")
Можно поподробнее про индекс с фильтром? Текст индекса, пожалуйста.
Подозреваю, что речь идет об ограничениях (constraints), но тогда какую реакцию вы ожидаете от системы?
Добавлено: Вт Июл 12, 2011 8:34 am Заголовок сообщения:
Речь не об ограничениях, а именно об индексе с фильтром:
Код:
CREATE UNIQUE NONCLUSTERED INDEX [IX_JRN_PARAMS_LONG] ON [dbo].[JRN_PARAMS]
(
[J_ID] ASC,
[PRM_ID] ASC
)
INCLUDE ( [PRM_LONG])
WHERE ([PRM_LONG] IS NOT NULL)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
На тестовой базе такой индекс содержит примерно 1/10 часть записей, т.е. 9/10 - записи с PRM_LONG is null
Добавлено: Вт Июл 12, 2011 11:32 am Заголовок сообщения:
kris писал(а):
Речь не об ограничениях, а именно об индексе с фильтром:
На тестовой базе такой индекс содержит примерно 1/10 часть записей, т.е. 9/10 - записи с PRM_LONG is null
Да дело ведь не в ошибке, т.к. причина ее и так понятна:
Msg 1934, Level 16, State 1, Line 3
UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
Дело в том, можно ли изменить SET QUOTED_IDENTIFIER off на on?
Добавлено: Ср Июл 13, 2011 9:47 am Заголовок сообщения:
kris писал(а):
Дело в том, можно ли изменить SET QUOTED_IDENTIFIER off на on?
Боюсь, тут единственный способ проверить - экпериментальный.
Ибо не все запросы исполняются через в ХП, некоторые - скрыты в коде.
Имхо, проблем возникнуть не должно, ибо опция лишь открывает возможность указывать имена полей в кавычках. Надеюсь, никаких подводных камней там присутствовать не будет. Другое дело, стоит ли овчинка выделки? Предполаагется делать часто и густо запросы к JRN_PARAMS по условию PRM_LONG=<prm_id>?
select *
from JOURNAL J
inner join JRN_PARAMS JP on J.J_ID = JP.J_ID and JP.PRM_ID = @prm_id and PRM_LONG is not null
Овчинка в некоторых случаях стоит выделки... Если база большая, а запросы сложные, хоть и небольшие, но все равно создают множество блокировок из-за нескольких (десятков) джоинов.
При использовании индексов с фильтрами вообще надо быть осторожным.
Проверить "на обум", к сожалению, довольно сложно, т.к. база, на которой это надо делать - довольно большая и очень активно используется. Можно по голове получить в самый неожиданный момент
Попробую на какой-нить мелкой и легкодоступной - вдруг проконает?
Запросы не PRM_LONG=<prm_id>, а, например
При использовании индексов с фильтрами вообще надо быть осторожным.
Проверить "на обум", к сожалению, довольно сложно, т.к. база, на которой это надо делать - довольно большая и очень активно используется. Можно по голове получить в самый неожиданный момент
Попробую на какой-нить мелкой и легкодоступной - вдруг проконает?
Эт понятно, но почему не сделать тест в "песочнице"?
Добавлено: Чт Июл 14, 2011 8:54 am Заголовок сообщения:
Да все потому же... Я ж не знаю, где и когда может акцент переключить эту опцию? А в песочнице я как правило программирую, а не вношу документы или меняю настройки. В одной из тестовых баз я сделал - проблем пока не обнаружено, документы сохраняются и даже открываются но вот когда вылезет вава... и где...
Сделал. Если вылезут бока - напишу Главное - не забыть после очередного обновления структуры базы хранимки подправить...
Для Param и Fact - проблем нет
Переделал журнал - вылезли приоблемы при удалении документа...Источник - процедура ap_operation_delete, причину пока не нашел
У меня нет такой процедуры. Версия БД 404.
Да и собственно в джорнале нечего фильтровать... Там почти все поля не-нуловые. Процессорные затраты на фильтрацию и затраты на доп. индексы перекрывают потенциальный выигрыш.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах