Имею MS SQL 2017 Developer Edition и базу данных с In-memory optimized tables
Как корректно проверять эту базу на консистентность?
Про DBCC информация такая:
1. DBCC CHECKDB skips the memory-optimized tables in the database.
2. DBCC CHECKTABLE will fail for memory-optimized tables.
Здравствуйте, wety, Вы писали:
W>Имею MS SQL 2017 Developer Edition и базу данных с In-memory optimized tables W>Как корректно проверять эту базу на консистентность?
Backup/Restore? Я такого в проде еще не видел, поэтому такая проблема пока не возникала.
Здравствуйте, wety, Вы писали:
W>Как корректно проверять эту базу на консистентность?
DBCC CHECKTABLE are not supported with memory-optimized tables. To verify the integrity of the on-disk checkpoint files, perform a backup of the MEMORY_OPTIMIZED_DATA filegroup.
W>Как же так???
Фича направлена на максимальную производительность. Совершенно логично, что от поддержки некоторых вещей при этом пришлось отказаться.
Здравствуйте, _ABC_, Вы писали:
W>>Как корректно проверять эту базу на консистентность? _AB>
_AB>DBCC CHECKTABLE are not supported with memory-optimized tables. To verify the integrity of the on-disk checkpoint files, perform a backup of the MEMORY_OPTIMIZED_DATA filegroup.
W>>Как же так??? _AB>Фича направлена на максимальную производительность. Совершенно логично, что от поддержки некоторых вещей при этом пришлось отказаться.
Надёжность базы в таком случае оказалась околонулевой. То есть, MS говорит таким образом: используйте максимальную производительность, но данные у вас будут фиговые, как раз 146% и получится.
"Замечательно"!
Здравствуйте, BlackEric, Вы писали:
W>>Имею MS SQL 2017 Developer Edition и базу данных с In-memory optimized tables W>>Как корректно проверять эту базу на консистентность?
BE>Backup/Restore? Я такого в проде еще не видел, поэтому такая проблема пока не возникала.
В таком случае ничто не мешает восстановить опять-таки убитую неконсистентную базу. Во.
Должен же быть какой-то способ?
А Вы вообще часто пользуетесь DBCC?
Здравствуйте, wety, Вы писали:
W>В таком случае ничто не мешает восстановить опять-таки убитую неконсистентную базу. Во.
В общем случае да.
W>Должен же быть какой-то способ? W>А Вы вообще часто пользуетесь DBCC?
Я одно время развлекался починкой битых баз. Поэтому часто.
Здравствуйте, wety, Вы писали:
W>Надёжность базы в таком случае оказалась околонулевой.
To verify the integrity of the on-disk checkpoint files, perform a backup of the MEMORY_OPTIMIZED_DATA filegroup.
Для проверки используй бэкап файловой группы соответствующей. Если файлы побиты, то бэкап выдаст ошибку. У тебя будет время отреагировать — перенести данные их in-memory таблицы в обычные, например.
W>То есть, MS говорит таким образом: используйте максимальную производительность, но данные у вас будут фиговые, как раз 146% и получится.
Нет, MS говорит совсем не это. Но странно, что ты не понимаешь, что фича, дающая большую производительность, забирает что-то взамен. Иначе это была бы не фича, а часть обычного движка.
W>"Замечательно"!
Я, надеюсь, ты в курсе, что DBCC CHECKDB используется не для того, чтобы гарантировать "нефиговость" данных?
Да, в курсе.
Но отбирать достаточно большой функционал и даже не говорить о том, что возможно в будущем этот функционал всё же починят и он будет работать — убогая схема работы и производства софта.
В таком случае, при разработке чего-либо, нужно метить методы и свойства через Obsolete.
Но что-то я в последнее время не встречал проектов, где использовался бы этот атрибут. Во.
А как же Вы? Как же так???
Здравствуйте, wety, Вы писали:
BE>>Backup/Restore? Я такого в проде еще не видел, поэтому такая проблема пока не возникала.
W>В таком случае ничто не мешает восстановить опять-таки убитую неконсистентную базу. Во.
Если цикл Backup/Restore успешно проходит, то можно считать, что бд в порядке. Бекапы не восстановимыми бывают. Но если восстановилось, то проблем не припомню.
Здравствуйте, BlackEric, Вы писали:
BE>Если цикл Backup/Restore успешно проходит, то можно считать, что бд в порядке.
Как альтернативу dbcc checkdb для in-memory, достаточно сделать полный copy_only бэкап двух файл-групп — primary и in-memory.
Причем, их можно делать в null, чтобы дисковое пространство не занимать пустой проверкой. Восстанавливать не нужно.
