Не думаю что есть люди которые берут чужие скрипты и пихаюх их в прод без проверки. Так же после 2и3 скрипта я указал про моменты что есть - fillfactor, есть проверка по партиция (и переиндексация только фрагментированных партиций) и про условия. так же было указано что это общая light версия.
А ложное утверждение это может быть только с отличных fillfactor от стандартного 0.(100). "А зачем мне учитывать плотность страниц при перестройке индекса в общем случае без точной специфики работы базы. Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах." тут не говорилось для разных таблиц с разной спецификой работы с ними.
Предложенный мной и частью других статей (https://www.sqlservercentral.com/только там чаще про 80% говорят) но также везде сказано что нужно смотреть производительность.
Так же я ни где не указал что этот скрипт истина в последней инстанции. Написано о определенной проблеме и предпосылках. так же в конце статьи написано про разные настройки.
А зачем мне учитывать плотность страниц при перестройке индекса в общем случае без точной специфики работы базы. Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах. Вопрос изначальный в статье о том, что переиндексация нужна. А оставлять fill factor 0 чревато тем, что при любой вставке будет проходить разбиение и фрагментация будет расти слишком быстро. Но при этом и не желательно делать слишком много пустого пространства, из за которого плотность будет меньше. а общее условие suggested_fillfactor позволяет найти компромисс от полного заполнения станиц и как следствие каждодневное повышение фрагментации и сохранить плотность на должном уровне.
Кстати можешь попробовать на сервере выполнить запрос (корректный) просто закоментив обе строки с переиндексацией вот эти SET @command = N'ALTER INDEX ' .... и тогда будет проще увидеть где ошибка
Кажется в запросе где знаки потерялись при копирование у меня
DECLARE @FramentationReportTable_1 VARCHAR(255) SET @FramentationReportTable_1 = (SELECT top 1 table_name FROM Profiler.INFORMATION_SCHEMA.TABLES WHERE table_Name LIKE 'Fragmentation_GoldenHome_Treasure_NEW_2012_'+REPLACE(convert(varchar, getdate(), 102), '.', '_') + '%') print @FramentationReportTable_1
exec ('
select frag.db_name, frag.schema_name, frag.table_name, frag.index_name, frag.partition_num, case when frag.record_size*16 <= 403 then 95
when frag.record_size*16 <= 806 then 90 when frag.record_size*16 <= 1209 then 85 else 80 end as suggested_fillfactor
from Profiler.dbo.'+ @FramentationReportTable_1 +' frag where frag.page_count > 24 and frag.fragmentation >= 5 and frag.num = 1 and frag.index_type <>''HEAP'' order by frag.fragmentation desc')
Пока как предположение, без полного запроса. Что дата в таблице в базе profiler идет с датой от вчера. и по этому курсор не смог задаться (так как ищет от сегодня данные). Если это так то запрос должен выдать ошибку, и получить данные если будет SET @FramentationReportTable_1 = (SELECT top 1 table_name FROM Profiler.INFORMATION_SCHEMA.TABLES WHERE table_Name LIKE 'Fragmentation_GoldenHome_Treasure_NEW_2012'+REPLACE(convert(varchar, getdate()-1, 102), '.', '_') + '%')
select frag.db_name, frag.schema_name, frag.table_name, frag.index_name, frag.partition_num, case when frag.record_size16 <= 403 then 95 when frag.record_size16 <= 806 then 90 when frag.record_size*16 <= 1209 then 85 else 80 end as suggested_fillfactor
from Profiler.dbo.'+ @FramentationReportTable_1 +' frag where frag.page_count > 24 and frag.fragmentation >= 5 and frag.num = 1 and frag.index_type <>''HEAP'' order by frag.fragmentation desc')
Да, каждую ночь. Но из-за фрагментация таблицы, самых больших таблиц уже не хватало железа что бы переварить запросы (типо всяких select'ов от начало времен). Был еще вариант заставить программистов 1с переделать их обработки, но они не захотели)
Обновление статистики помогало только если день - два переиндексация не проходила. Если дольше то начинались тормоза. Сейчас (уже 3 месяца) переиндексация проходит каждую ночь и тормозов больше не наблюдается. Так что да, помогло решить исходную проблему.
Не думаю что есть люди которые берут чужие скрипты и пихаюх их в прод без проверки. Так же после 2и3 скрипта я указал про моменты что есть - fillfactor, есть проверка по партиция (и переиндексация только фрагментированных партиций) и про условия. так же было указано что это общая light версия.
А ложное утверждение это может быть только с отличных fillfactor от стандартного 0.(100). "А зачем мне учитывать плотность страниц при перестройке индекса в общем случае без точной специфики работы базы. Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах." тут не говорилось для разных таблиц с разной спецификой работы с ними.
Предложенный мной и частью других статей (https://www.sqlservercentral.com/только там чаще про 80% говорят) но также везде сказано что нужно смотреть производительность.
Так же я ни где не указал что этот скрипт истина в последней инстанции. Написано о определенной проблеме и предпосылках. так же в конце статьи написано про разные настройки.
А зачем мне учитывать плотность страниц при перестройке индекса в общем случае без точной специфики работы базы. Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах. Вопрос изначальный в статье о том, что переиндексация нужна. А оставлять fill factor 0 чревато тем, что при любой вставке будет проходить разбиение и фрагментация будет расти слишком быстро. Но при этом и не желательно делать слишком много пустого пространства, из за которого плотность будет меньше. а общее условие
suggested_fillfactorпозволяет найти компромисс от полного заполнения станиц и как следствие каждодневное повышение фрагментации и сохранить плотность на должном уровне.вот тут как раз написано в какой строке ошибка. нужно смотреть может где-то данные не передаются, или потерялся какой ни будь символ
Это больше похоже на ошибку из лога. Я имел ввиду new quary весь 2ой или 3й шаг из статьи на сервере выполнить. закометив строку с переиндексации.
Тоже смотрю у тебя часть запроса потерялась при копирование.
должно быть
IF @@FETCH_STATUS < 0 BREAKа у тебя IF @FETCH_STATUSS < 0 BREAK
Кстати можешь попробовать на сервере выполнить запрос (корректный) просто закоментив обе строки с переиндексацией вот эти SET @command = N'ALTER INDEX ' .... и тогда будет проще увидеть где ошибка
А пришли, весь запрос который у тебя получился в скрипте, который не работает (насколько я понимаю это номер 2 должен быть что у меня в статье)
Кажется в запросе где знаки потерялись при копирование у меня
DECLARE @FramentationReportTable_1 VARCHAR(255)
SET @FramentationReportTable_1 = (SELECT top 1 table_name FROM Profiler.INFORMATION_SCHEMA.TABLES WHERE table_Name LIKE 'Fragmentation_GoldenHome_Treasure_NEW_2012_'+REPLACE(convert(varchar, getdate(), 102), '.', '_') + '%')
print @FramentationReportTable_1
exec ('
select
frag.db_name,
frag.schema_name,
frag.table_name,
frag.index_name,
frag.partition_num,
case
when frag.record_size*16 <= 403 then 95
when frag.record_size*16 <= 806 then 90
when frag.record_size*16 <= 1209 then 85
else 80
end as suggested_fillfactor
from Profiler.dbo.'+ @FramentationReportTable_1 +' frag
where frag.page_count > 24 and frag.fragmentation >= 5 and frag.num = 1 and frag.index_type <>''HEAP''
order by frag.fragmentation desc')
Ой я тогда в запросе, который кинул _ забыл после имени БД 'Fragmentation_GoldenHome_Treasure_NEW_2012_' нужно
Пока как предположение, без полного запроса. Что дата в таблице в базе profiler идет с датой от вчера. и по этому курсор не смог задаться (так как ищет от сегодня данные). Если это так то запрос должен выдать ошибку, и получить данные если будет SET @FramentationReportTable_1 = (SELECT top 1 table_name FROM Profiler.INFORMATION_SCHEMA.TABLES WHERE table_Name LIKE 'Fragmentation_GoldenHome_Treasure_NEW_2012'+REPLACE(convert(varchar, getdate()-1, 102), '.', '_') + '%')
В базе профайлер таблицы с именами такого вида Fragmentation_GoldenHome_Treasure_NEW_2012дата ?
Вот этот запрос выдает результат или ошибку?
DECLARE @FramentationReportTable_1 VARCHAR(255)
SET @FramentationReportTable_1 = (SELECT top 1 table_name FROM Profiler.INFORMATION_SCHEMA.TABLES WHERE table_Name LIKE 'Fragmentation_GoldenHome_Treasure_NEW_2012'+REPLACE(convert(varchar, getdate(), 102), '.', '_') + '%')
print @FramentationReportTable_1
exec ('
select
frag.db_name,
frag.schema_name,
frag.table_name,
frag.index_name,
frag.partition_num,
case
when frag.record_size16 <= 403 then 95 when frag.record_size16 <= 806 then 90
when frag.record_size*16 <= 1209 then 85
else 80
end as suggested_fillfactor
from Profiler.dbo.'+ @FramentationReportTable_1 +' frag
where frag.page_count > 24 and frag.fragmentation >= 5 and frag.num = 1 and frag.index_type <>''HEAP''
order by frag.fragmentation desc')
Да, каждую ночь. Но из-за фрагментация таблицы, самых больших таблиц уже не хватало железа что бы переварить запросы (типо всяких select'ов от начало времен). Был еще вариант заставить программистов 1с переделать их обработки, но они не захотели)
Можно имя БД?
Обновление статистики помогало только если день - два переиндексация не проходила. Если дольше то начинались тормоза. Сейчас (уже 3 месяца) переиндексация проходит каждую ночь и тормозов больше не наблюдается. Так что да, помогло решить исходную проблему.
Ну хоть нормальная инструкция с законным волеизъявлением, а не давайте на changerorg петицию подпишем...
Ни когда не думал, что импортозамещение серверов переклейкой шильдика, применят на сайтах
Epic начала работать через xsolla до февральских событий, и продолжила с ней работать после.