2016-09-21 1 views
0

Согласно этой статье, и несколько других, которые я нашел: Performance best practices for SQL ServerПочему лучшие практики сказать вам, чтобы отключить кэширование на диск журнала в SQL Server на лазурном VM

Это считается хорошей практикой отключить кэширование на премиальных дисках хранения для дисков SQL Server Log. Однако я не могу найти нигде, что объясняет, почему.

У кого-нибудь есть понимание?

Позвольте мне добавить, что причина, по которой я вижу отключение кэша только для чтения на диске журнала, как проблема, заключается в том, что вам нужно настроить два отдельных пула хранилищ внутри виртуальной машины, что делает модернизацию/понижение VM внутри Azure более проблематичным и значительно менее производительным.

Например, скажем, что вы начинаете с DS V13, который имеет ограничение на 16 дисков, но около 6 из этих дисков могут быть увеличены до дросселирования (25000 IOP). Поскольку лучшие практики говорят о кеше только для чтения для данных и кеша для журналов, вы даете 8 из этих дисков данным и 8 в журнал.

Теперь сервер нуждается в обновлении, поэтому вы обновите его до DS V14. Теперь вы можете выполнить максимум 12 дисков до дросселирования (50000 IOP). Тем не менее, размер столбцов хранилища данных вашего хранилища составляет всего 8, который дросселируется до 40000 IOP. Таким образом, вы не используете полный потенциал IO.

Однако, если вы можете начать с DS V13 и назначить все 16 этих дисков в один пул устройств хранения, тогда поместите на него как журнал, так и данные. Вы можете обновить/понизить до самого DS V15 без каких-либо проблем, чтобы не использовать потенциал вашего полного потенциала для ввода в эксплуатацию.

Другой способ: если вы создадите единый пул хранения для всех 16 дисков, у вас будет значительно больше гибкости при обновлении/понижении рейтинга виртуальной машины. Если вам нужно создать два пула хранилищ, вы этого не сделаете.

+0

Я добавил Azure Storage обратно, потому что я думаю, что этот вопрос имеет больше общего с тем, чем все остальное. –

ответ

2

Мы рекомендуем настроить «Нет» кэш на премии дисковые хранилища, на которых хранятся файлы журналов. Файлы журналов имеют в основном операции с записью и не используют кеш ReadOnly. Две причины:

  1. Содержание законного кэша будет выведено из бесполезных данных из журнала.
  2. Журнальные записи также будут потреблять кеш BW/IOPS. Если кеш включен на диске (ReadOnly или ReadWrite), каждая запись на этом диске также будет записывать эти данные в кеш. Каждое чтение также будет доступным/помещенным в кеш данных. Таким образом, каждый IO попадает в кеш, если кеш включен.

Спасибо, Аун

+0

Вы имеете в виду «мы рекомендуем отключать» вместо «мы рекомендуем устанавливать»? Если это так, походит на вескую причину. –

+0

Чтобы уточнить # 2, когда вы включили кеш ReadOnly (не кеш ReadWrite), каждая * запись * на диск также записывается в кеш ReadOnly? –

+0

Спасибо, Джош. Отредактировал мой ответ. Мы рекомендуем установить для параметра «Кэш» значение «Нет» для журналов. –

1

Файлы журналов используются как часть восстановления и могут помочь восстановить базу данных до определенного момента времени. Наличие поврежденных данных в файле журнала с отключением питания или жесткой перезагрузкой не очень хорошо работает с MSSQL. См. Ниже статью от MS, они относятся к более старым версиям SQL, но цель файла журнала не изменилась.

Информация об использовании дисковода тайники с SQL Server, что каждый администратор базы данных должен знать
https://support.microsoft.com/en-us/kb/234656

Описание контроллеров кэширования дисков в SQL Server
https://support.microsoft.com/en-us/kb/86903

+0

Итак, объясните, почему вы не хотите включать кэширование записи, но я ничего не вижу в кэшировании только для чтения. –

+0

Я считаю, что журналы никогда не читаются, только когда вы запрашиваете функции Change Data Capture, они выглядят так, что безопаснее не допускать кеширования на диске журнала. Может быть некоторый код, который проверяет чтение, которое может выйти из синхронизации после записи. – Josh

+0

Репликация также использует журналы, забыл об этом. Кэширование лог-диска может привести к потере данных, если произошел сбой, но произошла запись, а последняя транзакция чтения - 100 мс, слишком старая из кэша чтения. – Josh