Кэширование записи на 2-х массивах AcceleRaid 170
Модераторы: Trinity admin`s, Free-lance moderator`s
Кэширование записи на 2-х массивах AcceleRaid 170
Хочу создать на одном канале AcceleRaid 170 два массива - RAID0+1 и RAID1. Возможно ли в настройках Mylex указать, что бы кеширование записи RAID0+1 было включено, а RAID1 - выключено?
На RAID0+1 хочу положит базы SQL, а на RAID1 - журнал транзакций.
На RAID0+1 хочу положит базы SQL, а на RAID1 - журнал транзакций.
А зачем?
Зачем? Если бы наоборот - ещё хоть какой-то смыслAnton писал(а):На RAID0+1 хочу положит базы SQL, а на RAID1 - журнал транзакций.

Но тоже не стоит...
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
[quote="Anton"
По-моему, вполне логично.[/quote]
Не совсем
Дело в том, что чтение из журнала транзакций происходит исключительно при откате либо разовом сборе статистики. Все остальное время туда происходит запись - постоянно, последовательно, небольшими порциями, причем до формирования соответствующей записи в этом журнале транзакция не будет ни открыта, ни закрыта, и действий никаких производиться не будет. Причем, при потере даннного журнала будут потеряны последние незакрытые(невыполнен Commit или Rollback) транзакции - и только.
Что касается БД - там преобладающая операция - именно чтение. И именно к возможной потере блоков БД стоит относиться наиболее трепетно. И дело тут - в самом SQL- сервере: его кэш делится на несколько частей: кэш запросов (хранятся "разобранные" деревья наиболее часто выполняемых запросов) и блочный кэш (хранятся блоки/страницы БД). Вот последний тупо хранит блоки/страницы БД (юниты, привязывающие логическую структуру БД к ее физической организации - хранят собственно данные БД). Блочный кэш, в свою очередь, делится на кэши чтения и отложенной записи (Lazy Write). Кэш записи пишет при следующих условиях в порядке приоритета, в начале - наивысший: shutdown; достижение по времени некоторого интервала между операциями записи; заполнение буфера записи. Записывающий демон БД будет считать операцию записи выполненной с момента ее фактической передачи контроллеру, а у того - своя Lazy Write.
Уф... Вот.
По-моему, вполне логично.[/quote]
Не совсем

Дело в том, что чтение из журнала транзакций происходит исключительно при откате либо разовом сборе статистики. Все остальное время туда происходит запись - постоянно, последовательно, небольшими порциями, причем до формирования соответствующей записи в этом журнале транзакция не будет ни открыта, ни закрыта, и действий никаких производиться не будет. Причем, при потере даннного журнала будут потеряны последние незакрытые(невыполнен Commit или Rollback) транзакции - и только.
Что касается БД - там преобладающая операция - именно чтение. И именно к возможной потере блоков БД стоит относиться наиболее трепетно. И дело тут - в самом SQL- сервере: его кэш делится на несколько частей: кэш запросов (хранятся "разобранные" деревья наиболее часто выполняемых запросов) и блочный кэш (хранятся блоки/страницы БД). Вот последний тупо хранит блоки/страницы БД (юниты, привязывающие логическую структуру БД к ее физической организации - хранят собственно данные БД). Блочный кэш, в свою очередь, делится на кэши чтения и отложенной записи (Lazy Write). Кэш записи пишет при следующих условиях в порядке приоритета, в начале - наивысший: shutdown; достижение по времени некоторого интервала между операциями записи; заполнение буфера записи. Записывающий демон БД будет считать операцию записи выполненной с момента ее фактической передачи контроллеру, а у того - своя Lazy Write.
Уф... Вот.

-
- Advanced member
- Сообщения: 138
- Зарегистрирован: 19 окт 2002, 15:49
- Откуда: г. Волжский, Волгоградская область
- Контактная информация:
2 BTБ!
У меня изначально шла речь о A170, и вряд ли его можно отнести к "Полноценный RAID-контроллер с BBU".
"Чем поможет кеширование на запись скорости чтения и отказоустойчивости?" - конечно ничем, так я про кеширование на запись и не писАл (массив RAID0+1)
2 a_shats
Отключать кеширование на запись - по-моему, это следует из статьи на support.microsoft.com #86903 "INF: SQL Server and Caching disk Controllers"
"Записывающий демон БД будет считать операцию записи выполненной с момента ее фактической передачи контроллеру, а у того - своя Lazy Write." - вот-вот, а контроллер безбатарейный, и у диска 8Mb кеша, из которых, будем считать, 4 на запись. И о какой целостности данных может идти речь в случае пропадания эл.питания?
У меня изначально шла речь о A170, и вряд ли его можно отнести к "Полноценный RAID-контроллер с BBU".
"Чем поможет кеширование на запись скорости чтения и отказоустойчивости?" - конечно ничем, так я про кеширование на запись и не писАл (массив RAID0+1)
2 a_shats
Отключать кеширование на запись - по-моему, это следует из статьи на support.microsoft.com #86903 "INF: SQL Server and Caching disk Controllers"
"Записывающий демон БД будет считать операцию записи выполненной с момента ее фактической передачи контроллеру, а у того - своя Lazy Write." - вот-вот, а контроллер безбатарейный, и у диска 8Mb кеша, из которых, будем считать, 4 на запись. И о какой целостности данных может идти речь в случае пропадания эл.питания?
Признаю, неточно выразился. В моем первом посте был вопрос, можно ли на одном контроллере для разных массивов включать разные параметры кеширования - ответ конкретный "можно".
Второй же пост был ответом на Ваш, с разъяснением, почему хочу разместить данные по массивам именно так, и упор хотел сделать именно на выключении кеша записи массива RAID1. На массиве же RAID0+1 кеш оставить по умолчанию, т.е включенным и на чтение, и на запись.
Тема плавно перетекла в обсуждение связки "SQL - storage subsystem"
Второй же пост был ответом на Ваш, с разъяснением, почему хочу разместить данные по массивам именно так, и упор хотел сделать именно на выключении кеша записи массива RAID1. На массиве же RAID0+1 кеш оставить по умолчанию, т.е включенным и на чтение, и на запись.
Тема плавно перетекла в обсуждение связки "SQL - storage subsystem"
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Да что Вы к BBU прицепились ? У Вас что - УПСа нет, что ли ? 
А если серьезно - то, на мой взгляд, Вы выбрали не слишком надежный по Вашим же критериям (WB на самой базе ведь включен?
) вариант кэширования. Что касается упомянутого Вами inf, то- у Микрософт вообще очень оригинальный взгляд на построение SQL-сервера. Проблема здесь в том, что:
- при наличии контроллера с собственным кэшем файловый кэш ОС работает несколько по-иному (только на чтение)
- MSSQL пишет "мимо" файлового кэша ОС вообще, безотносительно наличия контроллера с собственным кэшем, и, в результате, в отличие от конкурирующих пакетов может более-менее надежно и быстро зафиксировать окончание операции записи. При наличии WB кэша на контроллере этот фокус не проходит. Оттого и забота об отключении WB
.
Что, собственно, хотел посоветовать - если есть УПС - включайте WB. И - на журнал транзакций - тоже - если хотите получить прирост производительности. А если хотите пущей надежности
- то отключите WB вообще (на оба массива), и увеличьте объем выделенной MSSQL оперативки (как я уже говорил, у него собственный блочный кэш).

А если серьезно - то, на мой взгляд, Вы выбрали не слишком надежный по Вашим же критериям (WB на самой базе ведь включен?

- при наличии контроллера с собственным кэшем файловый кэш ОС работает несколько по-иному (только на чтение)
- MSSQL пишет "мимо" файлового кэша ОС вообще, безотносительно наличия контроллера с собственным кэшем, и, в результате, в отличие от конкурирующих пакетов может более-менее надежно и быстро зафиксировать окончание операции записи. При наличии WB кэша на контроллере этот фокус не проходит. Оттого и забота об отключении WB

Что, собственно, хотел посоветовать - если есть УПС - включайте WB. И - на журнал транзакций - тоже - если хотите получить прирост производительности. А если хотите пущей надежности

Совет опасный, но если можно пожертвовать последними транзакциями и регулярно делать бэкап лога...a_shats писал(а):если есть УПС - включайте WB. И - на журнал транзакций - тоже - если хотите получить прирост производительности
Угу.a_shats писал(а):А если хотите пущей надежности- то отключите WB вообще (на оба массива)
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя