Полез в словари искать незнакомое слово и не нашёл.
Зато нашёл глагол «Транскрибировать», значением которого оказалось «Производить транскрипцию».
Значит правильно называется, спасибо.
Мы хотим попробовать выкинуть in-memory таблицу в отдельную бд на том же сервере, где вообще нет не-inmemory таблиц. В основной базе таблицу грохнуть и создать под её именем синоним, который будет смотреть на таблицу в новой бд. Если получится, такую базу и в ag можно будет включить, чтобы вместе ездили в случае файловера.
А вы проверяли размер файлов относящихся к этой базе с помощью, прошу прощения, файлового менеджера?
На диске занимает столько же, сколько я получаю запросом к sys.database_flies. Воспроизвести эту ситуацию и посмотреть размер на диске с помощью вашего любимого файлового менеджера вы можете минуты за 3 с использованием скриптов в посте.
Ну, целью поста было предупредить тех, кто планирует использовать In-Memory OLTP, или использует, но ещё не столкнулся с описанным, а не сказать, что технология фуфло и использовать её не стоит. Те или иные проблемы будут с любым решением.
Как раз таки фильтруемые индексы проявляются при фильтрациях и не важно где-в update, delete или merge.
ну я же специально привёл пример — где при использовании merge проблема есть, а при использовании update + insert — проблемы нет.
Я изначально «прицепился» к этой вашей фразе:
В данном случае достаточно научиться правильно писать merge и все.
очень уж она категорично звучит и вот мы выяснили, что, как минимум, кроме правильного написания merge нужно ещё не использовать filtered index'ы.
Мне позиция «авторитетов» гораздо более близка. Они говорят менее квалифицированным людям — у merge есть проблемы, они могут выстрелить, лучше их не использовать. Вы пишете в комментариях — я использовал и использую, всё ок, не надо бояться. При этом не оговариваете условия использования.
При использовании merge проблема проявляется, при использовании update+insert — нет, но это проблема не merge? Окей. Но тогда в первом вашем сообщении хотелось бы видеть, что кроме умения готовить merge, нужно ещё отказаться от filtered indexes. Может ещё что-то использовать не стоит?
Что касается "автора материала не в курсе" — ну, даже не знаю что тут сказать.
Ну вот пример бага, который воспроизводится на не самых древних версиях, которые ещё много где используются.
The MERGE plan may fail at execution time depending on the order in which rows are processed, and the distribution of data in the database. Worse, a previously solid MERGE query may suddenly start to fail unpredictably if a filtered unique index is added to the merge target table at any point.
Bug reproduces on:
SQL Server 2014 (SP3-CU2) build 12.0.6214.1
SQL Server 2012 (SP4-GDR) build 11.0.7462.6
Да, там же описаны воркаэраунды, но, считается ли это предсказуемым и допустимым поведением для mission-critical систем? Как по мне — нет.
Я не говорил, что у встроенной репликации нет проблем
Ну да, вы запретили мне их упоминать, пока я не напишу свою без этих проблем.
Задачи разные, квалификация разная, есть множество инсталляций и 2008, и 2012, и 2016 без патчей, где проблемы присутствуют. Говорить, что «надо просто уметь его готовить» — не корректно. Вы предполагаете, что Аарон Бертранд не умеет его готовить?
Да, мне тоже нравится MERGE, он прикольный и удобный, но в критически-важные участки я его без веских причин не потащу — предсказуемость важнее.
Вы писали, что MERGE работает быстрее UPDATE — может быть есть конкретные примеры?
Перед тем как критиковать встроенную репликацию, попробуйте написать свою.
ИМХО, странное предложение. Да репликация сложный механизм, но в ней есть проблемы и приводить её в пример в контексте «у меня с Merge всё работает и у репликации с Merge нет проблем» тоже странно, потому что репликация может привести ко множеству проблем безотносительно того — могу ли я, или кто-то другой, сделать лучше.
Сколько же на этой таблице индексов, что удаление 10 тысяч строк занимало минуту, а перенос сотен миллионов (вы писали про удаление только 100 млн.) занимает час?
И сколько потом все эти индексы и констрейнты снова строились?
Допустимо, кроме того, поместить YEAR в выражение GROUP BY, так как выражение SELECT выполняется первым. В результате интерпретатору, после выполнения этого выражения, уже будет известно о том, что в запросе имеется столбец с именем YEAR:
Вообще, интересно — это часть стандарта или нет? Для MS SQL Server — это процитированное утверждение ложно, обращаться к столбцу по псевдониму в GROUP BY в нём нельзя. SQL Bolt и Towads Data Science, без привязки к СУБД, тоже говорят о том, что GROUP BY «выполняется до» SELECT. А PostgreSQL позволяет такое, MySQL, видимо тоже.
Спасибо!
Насколько я понимаю ситуацию с columnestor'ами — размер сегмента не ограничивается (хотя не знаю не пытается ли он сегмент целиком прочитать и что будет, если не сможет), но в памяти больше чем 352 МБ «держаться» не будет. Причём ограничение там на экземпляр, т.е. несколько DWH-запросов в разные БД могут сильно конкурировать за память.
Спасибо за статью. Имхо, стоит добавить, что и для columnstore индексов, и для in-memory oltp в express edition даже более смешные ограничения, чем на всё остальное.
upd: Увидел, что про ограничения для columnstore написано, сорри.
if you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system.
Даже в вашем эксперименте это starting value вполне неплохо себя показывает. Сделаете таблицу в 4 раза больше и, вероятно, разница на сканах тоже не будет столь заметной.
Конечно было бы здорово иметь столько ОЗУ, чтобы туда влезало всё, что нужно. И, конечно, рекомендации — это всегда что-то усреднённое, подходящее не всем, но они дают хоть какую-то отправную точку.
Спасибо за пост.
Что интересно, как раз для индексов — рекомендации о размере shared_buffers в 1/4 ОЗУ вполне себе работают. При поиске по индексу разница во времени выполнения не велика.
Вот для скана проигрыш на рекомендуемом размере очевиден, но, неочевидно, будет ли при реальной нагрузке картина такой же.
Ну, Transcribe - Транскрибировать - производить транскрипцию
Зато нашёл глагол «Транскрибировать», значением которого оказалось «Производить транскрипцию».
Значит правильно называется, спасибо.
На видео натыкался, но текст всегда круче).
Для тех, кто снимает диф-бэкапы, такой ваш бэкап может стать огромным (и очень неприятным) сюрпризом. Добавьте ключ COPY_ONLY к бэкапу.
Мы хотим попробовать выкинуть in-memory таблицу в отдельную бд на том же сервере, где вообще нет не-inmemory таблиц. В основной базе таблицу грохнуть и создать под её именем синоним, который будет смотреть на таблицу в новой бд. Если получится, такую базу и в ag можно будет включить, чтобы вместе ездили в случае файловера.
Спасибо!
На диске занимает столько же, сколько я получаю запросом к sys.database_flies. Воспроизвести эту ситуацию и посмотреть размер на диске с помощью вашего любимого файлового менеджера вы можете минуты за 3 с использованием скриптов в посте.
Я изначально «прицепился» к этой вашей фразе:
очень уж она категорично звучит и вот мы выяснили, что, как минимум, кроме правильного написания merge нужно ещё не использовать filtered index'ы.
Мне позиция «авторитетов» гораздо более близка. Они говорят менее квалифицированным людям — у merge есть проблемы, они могут выстрелить, лучше их не использовать. Вы пишете в комментариях — я использовал и использую, всё ок, не надо бояться. При этом не оговариваете условия использования.
При использовании merge проблема проявляется, при использовании update+insert — нет, но это проблема не merge? Окей. Но тогда в первом вашем сообщении хотелось бы видеть, что кроме умения готовить merge, нужно ещё отказаться от filtered indexes. Может ещё что-то использовать не стоит?
Что касается "автора материала не в курсе" — ну, даже не знаю что тут сказать.
Да, там же описаны воркаэраунды, но, считается ли это предсказуемым и допустимым поведением для mission-critical систем? Как по мне — нет.
Ну да, вы запретили мне их упоминать, пока я не напишу свою без этих проблем.
Да, мне тоже нравится MERGE, он прикольный и удобный, но в критически-важные участки я его без веских причин не потащу — предсказуемость важнее.
Вы писали, что MERGE работает быстрее UPDATE — может быть есть конкретные примеры?
ИМХО, странное предложение. Да репликация сложный механизм, но в ней есть проблемы и приводить её в пример в контексте «у меня с Merge всё работает и у репликации с Merge нет проблем» тоже странно, потому что репликация может привести ко множеству проблем безотносительно того — могу ли я, или кто-то другой, сделать лучше.
известная своей беспроблемностью)?
И сколько потом все эти индексы и констрейнты снова строились?
Вообще, интересно — это часть стандарта или нет? Для MS SQL Server — это процитированное утверждение ложно, обращаться к столбцу по псевдониму в GROUP BY в нём нельзя. SQL Bolt и Towads Data Science, без привязки к СУБД, тоже говорят о том, что GROUP BY «выполняется до» SELECT. А PostgreSQL позволяет такое, MySQL, видимо тоже.
Насколько я понимаю ситуацию с columnestor'ами — размер сегмента не ограничивается (хотя не знаю не пытается ли он сегмент целиком прочитать и что будет, если не сможет), но в памяти больше чем 352 МБ «держаться» не будет. Причём ограничение там на экземпляр, т.е. несколько DWH-запросов в разные БД могут сильно конкурировать за память.
Спасибо за статью. Имхо, стоит добавить, что и для columnstore индексов, и для in-memory oltp в express edition даже более смешные ограничения, чем на всё остальное.
upd: Увидел, что про ограничения для columnstore написано, сорри.
Даже в вашем эксперименте это starting value вполне неплохо себя показывает. Сделаете таблицу в 4 раза больше и, вероятно, разница на сканах тоже не будет столь заметной.
Конечно было бы здорово иметь столько ОЗУ, чтобы туда влезало всё, что нужно. И, конечно, рекомендации — это всегда что-то усреднённое, подходящее не всем, но они дают хоть какую-то отправную точку.
Что интересно, как раз для индексов — рекомендации о размере shared_buffers в 1/4 ОЗУ вполне себе работают. При поиске по индексу разница во времени выполнения не велика.
Вот для скана проигрыш на рекомендуемом размере очевиден, но, неочевидно, будет ли при реальной нагрузке картина такой же.