А можете прояснить - как работает DETACH | DELETE PARTITION? Как условный delete "из индекса" - т.е. для каждой строки в отсоединяемой партиции нужно будет найти и отметить строку в глобальном индексе? Или же записи остаются в индексе условно "живыми", а удалёнными отмечаются только при попытке доступа к ним?
Меня удивляет отсутвие секций и необходимости online-ребилда в VLDB) но - на нет и суда нет)
Низкий процент заполненности страниц вполне может быть причиной для ребилда, даже если "внешняя" фрагментация не так уж велика.
Спасибо
Если добавить проверку фрагментации для HOT-Таблиц, то может ведь и оказаться, что вполне хватит UPDATE STATISTICS. И таблицы останутся онлайн, и кэши не вымываются, и в журнал транзакций записи практически нет (реплики говорят спасибо)).
Добрый день. Спасибо за труд, возникло несколько вопросов:
А почему для перестроения индексов вы используете deprecated DBCC DBREINDEX, а не ALTER INDEX ... REBUILD? Rebuild позволяет указывать online/offline, явно ограничивать степень параллелизма, в относительно новых версиях добавлены всякие приятности, типа resumable операций и wait at low priority. Плюс даёт возможность перестраивать только нужные секции индекса. У вас нет секционированных индексов?
Почему для не-HOT таблиц учитывается только "внешняя" фрагментация и не учитывает процент заполненности страниц?
Зачем везде fillfactor 90? В т.ч. на [DBA].[ReindexJobLog].
Почему, для HOT таблиц не учитывается никакая фрагментация и таблицы принудительно перестраиваются полностью?
ЕМНИП, табличку с 5-30% даже из актуальной документации убрали.
Перед НГ увидел рекламу этого кресла и аж загорелся. Объездил полгорода, в итоге всё-таки нашёл где оно есть выставленное в зале, посидел и это, правда, восторг для спины. Но для меня оказался очень неудобным подголовник. Мой рост под два метра и подголовник упирается и давит куда-то в шею в макстимальном верхнем положении. От покупки пока отказался. Может ещё выпустят версию для людей повыше.
Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах
Это ложное утверждение. C fill factor < 100 вы скорее её уменьшаете, но поскольку не отслеживаете - подтвердить или опровергнуть это не получится. Однако люди, которые запустят ваши скрипты, могут сильно удивиться, что индексы выросли, и памяти теперь нужно больше, чем до дефрагментации.
suggested_fillfactor позволяет найти компромисс от полного заполнения станиц и как следствие каждодневное повышение фрагментации и сохранить плотность на должном уровне
А кем он suggested? Зачем он безльтернативно suggested для всех таблиц с фрагментацией больше 5%? А если это историческая таблица с индексом по дате, в которой все изменения происходят в последнем месяце?
А как ваш скрипт учитывает плотность страниц, о которой вы пишете в тексте? Ну, не считая того, что уменьшает её, уменьшая для всех таблиц fill factor?
Результат в примере с подзапросами может отличаться от оптимизированного варианта с джойнами, если у клиента не было заказов.
Пример с процедурой выглядит максимально странно:
вложенные циклы - это прям не круто, особенно для такой задачи (вот бы посмотреть на sql-запрос, может он и не такой уж сложный)?
может "терять" данные, если SUM(Quantity) будет одинаковым для 2 и более продуктов, сортировки в запросе нет, на каждый вызов, теоретически, может возвращаться разный продукт;
"сбрасывается" только одна переменнаяv_max_quantity , проверок никаких нет, а что произойдёт, если в предыдущей итерации у clinet_id = 123 был заказ, а у следующего клиента client_id = 124 заказов не было?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
SELECT * FROM MyTable WHERE ID = 12345
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
как предлагаете аттестовывать специалистов по ним?
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
with x (id, smth) as (select 1, 'smth' union all select 2, 'smth else' union all select 3, 'anthr')
, y (id) as (select 1 union all select 2 union all select 1)
select *
from x
where id in (select id from y);
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)
Интересно, спасибо.
Спасибо за статью.
А можете прояснить - как работает DETACH | DELETE PARTITION? Как условный delete "из индекса" - т.е. для каждой строки в отсоединяемой партиции нужно будет найти и отметить строку в глобальном индексе? Или же записи остаются в индексе условно "живыми", а удалёнными отмечаются только при попытке доступа к ним?
Спасибо за ответ.
Меня удивляет отсутвие секций и необходимости online-ребилда в VLDB) но - на нет и суда нет)
Низкий процент заполненности страниц вполне может быть причиной для ребилда, даже если "внешняя" фрагментация не так уж велика.
Спасибо
Если добавить проверку фрагментации для HOT-Таблиц, то может ведь и оказаться, что вполне хватит
UPDATE STATISTICS. И таблицы останутся онлайн, и кэши не вымываются, и в журнал транзакций записи практически нет (реплики говорят спасибо)).Добрый день. Спасибо за труд, возникло несколько вопросов:
А почему для перестроения индексов вы используете deprecated
DBCC DBREINDEX, а неALTER INDEX ... REBUILD? Rebuild позволяет указывать online/offline, явно ограничивать степень параллелизма, в относительно новых версиях добавлены всякие приятности, типа resumable операций и wait at low priority. Плюс даёт возможность перестраивать только нужные секции индекса. У вас нет секционированных индексов?Почему для не-HOT таблиц учитывается только "внешняя" фрагментация и не учитывает процент заполненности страниц?
Зачем везде fillfactor 90? В т.ч. на
[DBA].[ReindexJobLog].Почему, для HOT таблиц не учитывается никакая фрагментация и таблицы принудительно перестраиваются полностью?
ЕМНИП, табличку с 5-30% даже из актуальной документации убрали.
dba -> разработчик БД
Лет семь уже, как бывший
Перед НГ увидел рекламу этого кресла и аж загорелся. Объездил полгорода, в итоге всё-таки нашёл где оно есть выставленное в зале, посидел и это, правда, восторг для спины. Но для меня оказался очень неудобным подголовник. Мой рост под два метра и подголовник упирается и давит куда-то в шею в макстимальном верхнем положении. От покупки пока отказался. Может ещё выпустят версию для людей повыше.
Это ложное утверждение. C fill factor < 100 вы скорее её уменьшаете, но поскольку не отслеживаете - подтвердить или опровергнуть это не получится. Однако люди, которые запустят ваши скрипты, могут сильно удивиться, что индексы выросли, и памяти теперь нужно больше, чем до дефрагментации.
А кем он suggested? Зачем он безльтернативно suggested для всех таблиц с фрагментацией больше 5%? А если это историческая таблица с индексом по дате, в которой все изменения происходят в последнем месяце?
А как ваш скрипт учитывает плотность страниц, о которой вы пишете в тексте? Ну, не считая того, что уменьшает её, уменьшая для всех таблиц fill factor?
Результат в примере с подзапросами может отличаться от оптимизированного варианта с джойнами, если у клиента не было заказов.
Пример с процедурой выглядит максимально странно:
вложенные циклы - это прям не круто, особенно для такой задачи (вот бы посмотреть на sql-запрос, может он и не такой уж сложный)?
может "терять" данные, если
SUM(Quantity)будет одинаковым для 2 и более продуктов, сортировки в запросе нет, на каждый вызов, теоретически, может возвращаться разный продукт;"сбрасывается" только одна переменная
v_max_quantity, проверок никаких нет, а что произойдёт, если в предыдущей итерации у clinet_id = 123 был заказ, а у следующего клиента client_id = 124 заказов не было?Есть примеры с замерами?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
Зачем там вообще distinct, в любом месте?
И зачем вообще вариант с IN, если есть с EXISTS.
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
На этот вопрос вы не ответили. Почему бы не использовать lateral?
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
т.е. выражение вида where not (smth = null) даст true (будет истинным)?
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)