Новый сервер 1С SQL(60users)
Модераторы: Trinity admin`s, Free-lance moderator`s
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
разве что ставить 2САС винта на лог. Но опять же нужно брать контройлер.
Зачем ? Предлагается внешний дисковый массив. И базу и лог на него - и все дела.
не сомневаюсь. но постоянно бэкапещейся лог транзакций не имеет такую ценность в принципе. а тем более для нас.
То есть у Вас бэкап идет на ленту, а электричество отключается избирательно, и даже в принципе не может отключиться в момент бэкапа ? И еще вопрос. Вы пробовали накатывать на базу лог, сбэкапленный на ходу ? И как ощущения ? :D
остановит на 3-5 минут пока сотрудник ИТ не кликнет несколько раз мышью в ЕМ. но повторюсь. вероятность крайне мала.
цель не оправдывает средства !!!!
Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ? :D
48 Гб какими модулями ? )
4 GB модулями, не вопрос - деньги Ваши
ЗЫ Посему я сразу и спрашивал насчёт цен по зап. частям Дабы не создавать вам проблем и не отнимать время
Это не проблема. Проблема будет, если мы Вам продадим того ежика, которого Вы сейчас хотите - а потом наш сервис будет рассказывать мне про меня много нового, а Вы, соответственно - им :D
Да, и на цену контроллера скидку дам, т.е. 1К у.е. со всей суммы, включая скидку на винты :D
Зачем ? Предлагается внешний дисковый массив. И базу и лог на него - и все дела.
не сомневаюсь. но постоянно бэкапещейся лог транзакций не имеет такую ценность в принципе. а тем более для нас.
То есть у Вас бэкап идет на ленту, а электричество отключается избирательно, и даже в принципе не может отключиться в момент бэкапа ? И еще вопрос. Вы пробовали накатывать на базу лог, сбэкапленный на ходу ? И как ощущения ? :D
остановит на 3-5 минут пока сотрудник ИТ не кликнет несколько раз мышью в ЕМ. но повторюсь. вероятность крайне мала.
цель не оправдывает средства !!!!
Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ? :D
48 Гб какими модулями ? )
4 GB модулями, не вопрос - деньги Ваши
ЗЫ Посему я сразу и спрашивал насчёт цен по зап. частям Дабы не создавать вам проблем и не отнимать время
Это не проблема. Проблема будет, если мы Вам продадим того ежика, которого Вы сейчас хотите - а потом наш сервис будет рассказывать мне про меня много нового, а Вы, соответственно - им :D
Да, и на цену контроллера скидку дам, т.е. 1К у.е. со всей суммы, включая скидку на винты :D
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
gs
А выкинуть лог за массив с БД будет не лучше ?
У вас есть другая информация ? поделитесь плиз.
Повреждение БД и одновременно повреждение лога - это фантастика. Вернее вероятность такая же, как с сервером и массивом предложенными вами.
Для нашей фирмы:
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.
2х процовые платформы я не рассматриваю вообще.В четырехпроцессорнике 24 слота памяти. В двухсокетниках - максимум 16, чаше 8. Ну вот и считайте.
Скидки это хорошо, но для меня сейчас не цель об этом уместнее говорить опосля того, как определюсь с железом!А насчет скидки - Вы подумайте. Мы ведь наверно неспроста готовы пожертвовать жадностью . Просто нам так спокойнее спать будет...
а поточнее? и насчёт цена на 2гб модулиМодуль 4ГБ стоит навскидку под тонну.
Да? ну значит я не так понял. я думал LSI Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int как раз для винды и логов.Зачем ? Предлагается внешний дисковый массив. И базу и лог на него - и все дела.
А выкинуть лог за массив с БД будет не лучше ?
Бэкап идёт на сервер в соседнем здании. электричество - ИБП и генератор на всё здание.То есть у Вас бэкап идет на ленту, а электричество отключается избирательно, и даже в принципе не может отключиться в момент бэкапа ?
на тестовых базах много раз. отлично ! на боевой не разу, но теория подтверждается людьми, столкнувшимися с подобными случаями.И еще вопрос. Вы пробовали накатывать на базу лог, сбэкапленный на ходу ? И как ощущения ?
У вас есть другая информация ? поделитесь плиз.
в какие десятки ? раз в сутки шринк. да и не буду я вообще трогать лог. запущу БД так, как есть, создав новый файл логаАга. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ?
Повреждение БД и одновременно повреждение лога - это фантастика. Вернее вероятность такая же, как с сервером и массивом предложенными вами.
Для нашей фирмы:
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.
зачем вообще трогать лог ? не пойму. Разве что, если вы рассматриваете случай повреждения самой БД, то с сервером, предложенным вами, будет та же ситуация.Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ?
пока в том, что это ёжик, вы меня не убедили :roll:Проблема будет, если мы Вам продадим того ежика, которого Вы сейчас хотите - а потом наш сервис будет рассказывать мне про меня много нового, а Вы, соответственно - им
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
Для прояснения, хочу задать вопрос, по схеме подключения, предлженного сервера:
Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.
Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.
Я правильно понимаю?
Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.
Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.
Я правильно понимаю?
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Да? ну значит я не так понял. я думал LSI Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int как раз для винды и логов.
А выкинуть лог за массив с БД будет не лучше ?
Чем лучше ? На массиве дублированы контроллеры, блоки питания, FC и SAS порты. На внутренней дисковой не дублировано вообще ничего.
на тестовых базах много раз. отлично ! на боевой не разу, но теория подтверждается людьми, столкнувшимися с подобными случаями.
У вас есть другая информация ? поделитесь плиз.
Хорошо, спрошу по-другому. Чем гарантирована целостность снятого на ходу лога ?
Повреждение БД и одновременно повреждение лога - это фантастика.
Чувствуется, что пока сами не попадете на такое - не поверите.
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.
За один-два часа вы восстановите работоспособность сервера, проверите ее, восстановите работоспособность ОС, проверите ее, накатите как бы целостный лог 5 ГБ на БД, проверите ее ?
Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.
Да.
Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.
Почти да. Контроллер там нельзя назвать 100% резервным - вполне можно использовать его производительность. При отказе любого (!) из контроллеров - да, массив продолжит работу на втором.
А выкинуть лог за массив с БД будет не лучше ?
Чем лучше ? На массиве дублированы контроллеры, блоки питания, FC и SAS порты. На внутренней дисковой не дублировано вообще ничего.
на тестовых базах много раз. отлично ! на боевой не разу, но теория подтверждается людьми, столкнувшимися с подобными случаями.
У вас есть другая информация ? поделитесь плиз.
Хорошо, спрошу по-другому. Чем гарантирована целостность снятого на ходу лога ?
Повреждение БД и одновременно повреждение лога - это фантастика.
Чувствуется, что пока сами не попадете на такое - не поверите.
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.
За один-два часа вы восстановите работоспособность сервера, проверите ее, восстановите работоспособность ОС, проверите ее, накатите как бы целостный лог 5 ГБ на БД, проверите ее ?
Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.
Да.
Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.
Почти да. Контроллер там нельзя назвать 100% резервным - вполне можно использовать его производительность. При отказе любого (!) из контроллеров - да, массив продолжит работу на втором.
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
a_shats
А если наоборот, то вообще не критично. Если массив с БД жив, то потеря лога транзакций вообще никак не отразится на данных. и понадобится всего 5-10 минут на создание нового лога транзакций. Я знаю кучу примеров, где админы лог выносят вообще на, так не любимый вами RAID0, потому как при целой БД лог совершенно не важен.
Лог транзакци(с опцией "Recoveru Model-Full") нужен только при повреждении самой БД ! А вы предлагаете их на один массив
а вот САТА счеталок у меня завалялась парочка, впрочем как и дисков
Кстати шансов, что рухнет ваш массив(с логами и БД) больше, чем вероятность, что одновременно рухнет ваш массив с БД и мой массив на САТА с логом.
А об этом я выше писал. потеря лога но с целой БД никак не отразится на работе. Потеря же БД, но с целым логом- большая вероятность восстановления всех данных до збоя. конечно для нас, не сильно отличается от потери одновременно БД и лога (как в вашем варианте), но в нашем случае, возможна потеря данных за час !
Кстати нашёл цену на SAS3041E-R и понял, что разница действительно не существенна. Но тут уже вопрос о конфигурации сервера под наши, конкретные задачи !
А лучше на мой взгляд тем, что лог и БД на совершенно разных массивах, и в случае потери массива с БД(что наименее вероятно, как вы утверждаете, хотя постоянно приводите в пример ) лог останется жив и актуален, а бэкапы лога скорее всего не понадобятся. хотя для нас это не шибко важно, но в теории это так.Чем лучше ?
А если наоборот, то вообще не критично. Если массив с БД жив, то потеря лога транзакций вообще никак не отразится на данных. и понадобится всего 5-10 минут на создание нового лога транзакций. Я знаю кучу примеров, где админы лог выносят вообще на, так не любимый вами RAID0, потому как при целой БД лог совершенно не важен.
Лог транзакци(с опцией "Recoveru Model-Full") нужен только при повреждении самой БД ! А вы предлагаете их на один массив
Ну БП на сервере тоже просто обязан дублироваться. ну а FC и SAS порты.....хорошо, но скажите, что будет, если умрёт "Fibre Channel adapter" ? что нам делать в таком случае ? И сколько это времени займёт ?На массиве дублированы контроллеры, блоки питания, FC и SAS порты. На внутренней дисковой не дублировано вообще ничего.
а вот САТА счеталок у меня завалялась парочка, впрочем как и дисков
тем же, чем гарантируют MS сохранность БД в обычном, рабочем режиме.Хорошо, спрошу по-другому. Чем гарантирована целостность снятого на ходу лога ?
Знаете, не обязательно самому попадать. Я руководствуюсь не только своим опытом, но и опытом других людей.Чувствуется, что пока сами не попадете на такое - не поверите.
Кстати шансов, что рухнет ваш массив(с логами и БД) больше, чем вероятность, что одновременно рухнет ваш массив с БД и мой массив на САТА с логом.
Ну почему вы опять рассматриваете вариант падения массива с БД ? Ведь БД то будет стоять на предложенном вами, суперотказоустойчивом массиве ! А критикуете вы мой массив на САТА, куда я хочу лог перенести. Дак давайте обсуждать потерю лога, а не БДЗа один-два часа вы восстановите работоспособность сервера, проверите ее, восстановите работоспособность ОС, проверите ее, накатите как бы целостный лог 5 ГБ на БД, проверите ее ?
А об этом я выше писал. потеря лога но с целой БД никак не отразится на работе. Потеря же БД, но с целым логом- большая вероятность восстановления всех данных до збоя. конечно для нас, не сильно отличается от потери одновременно БД и лога (как в вашем варианте), но в нашем случае, возможна потеря данных за час !
А в случае сбоя контройлера, переключение на другой автоматически ? И на сколько я понял, там 2а контройлера?Почти да. Контроллер там нельзя назвать 100% резервным - вполне можно использовать его производительность. При отказе любого (!) из контроллеров - да, массив продолжит работу на втором.
Кстати нашёл цену на SAS3041E-R и понял, что разница действительно не существенна. Но тут уже вопрос о конфигурации сервера под наши, конкретные задачи !
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Еще раз.Dave251 писал(а): А лучше на мой взгляд тем, что лог и БД на совершенно разных массивах, и в случае потери массива с БД(что наименее вероятно, как вы утверждаете, хотя постоянно приводите в пример ) лог останется жив и актуален, а бэкапы лога скорее всего не понадобятся. хотя для нас это не шибко важно, но в теории это так.
А если наоборот, то вообще не критично. Если массив с БД жив, то потеря лога транзакций вообще никак не отразится на данных. и понадобится всего 5-10 минут на создание нового лога транзакций. Я знаю кучу примеров, где админы лог выносят вообще на, так не любимый вами RAID0, потому как при целой БД лог совершенно не важен.
При отказе массива под логом БД встанет или нет ?
Именно. На один отказоустойчивый массив, с единым управлением и мониторингом, не зависящий никак от капризов ОС на сервере в том числе.Лог транзакци(с опцией "Recoveru Model-Full") нужен только при повреждении самой БД ! А вы предлагаете их на один массив
Есть мнение, что если у Вас помрет FC HBA - вам придется выбрасывать и сам сервер. Ибо статистика их отказов у нас стремится к нулю (если быть точным - 2 отказавших контроллера за 4-5 лет).Ну БП на сервере тоже просто обязан дублироваться. ну а FC и SAS порты.....хорошо, но скажите, что будет, если умрёт "Fibre Channel adapter" ? что нам делать в таком случае ? И сколько это времени займёт ?
C чего бы ? А вот то, что база при падении внутреннего массива встанет однозначно - это да. И восстановление ее в любом случае займет не 5 и не 10 минут - если Вам важен результат, конечно.Знаете, не обязательно самому попадать. Я руководствуюсь не только своим опытом, но и опытом других людей.
Кстати шансов, что рухнет ваш массив(с логами и БД) больше, чем вероятность, что одновременно рухнет ваш массив с БД и мой массив на САТА с логом.
При записи в файлы БД происходят следующие вещи:Ну почему вы опять рассматриваете вариант падения массива с БД ? Ведь БД то будет стоять на предложенном вами, суперотказоустойчивом массиве ! А критикуете вы мой массив на САТА, куда я хочу лог перенести. Дак давайте обсуждать потерю лога, а не БД
А об этом я выше писал. потеря лога но с целой БД никак не отразится на работе. Потеря же БД, но с целым логом- большая вероятность восстановления всех данных до збоя. конечно для нас, не сильно отличается от потери одновременно БД и лога (как в вашем варианте), но в нашем случае, возможна потеря данных за час !
- страницы SQL на запись кэшируются
- производится запись в лог без кэширования
- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД.
Напомнить, сколько Вы хотите иметь ОЗУ ? Вы готовы потерять несколько ГБайт информации в худшем случае (массив под логами падает во время перепроведения документов, к примеру) ?
Да.А в случае сбоя контройлера, переключение на другой автоматически ? И на сколько я понял, там 2а контройлера?
Ваши задачи не являются уникальными и имеют совершенно известные и стандартные решения. Можете пошерстить этот форум на предмет - тут их много.Кстати нашёл цену на SAS3041E-R и понял, что разница действительно не существенна. Но тут уже вопрос о конфигурации сервера под наши, конкретные задачи !
Вы ради копеечной экономии (на которую я уже Вам обещал дать скидку) пытаетесь городить ежа - плохо управляемую, сильно разнородную дисковую подсистему.
Еще раз прошу поверить на слово - такие ежи никакой радости админу не приносят. Только геморрой.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Крайне отрицательно. Обычно приводит к проблемам.Кстати ещё несколько вопросов !
Как вы относитесь к наращиванию памяти в серверах, модулями памяти разной ёмкости и от разных производителей ?
А смысл ? Диски надо считать не в полке - а в массиве.Есть ли полки с большим кол-вом места под диски и насколько отличается по цене ?
Отдельно - от сервера ? На массив - своя гарантия, точно такая же.Возможно ли приобретение массива отдельно и как это скажется на гарантии ?
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
a_shats
Но чесно говоря страшно представить, если таким "счастливчиком" окажусь я и жаль, что он весьма дорог.
a_shats
Да. так же как и при отказе массива с самой БД + лог. Хотя насколько я понял, по сказанному ниже, вероятность падения массива предложенного вами практически равна нулю ?Еще раз.
При отказе массива под логом БД встанет или нет ?
"не зависящий никак от капризов ОС на сервере" - соглашусь, достаточно веский аргумент в пользу вашей системы.На один отказоустойчивый массив, с единым управлением и мониторингом, не зависящий никак от капризов ОС на сервере в том числе.
обнадёживающая статистика. Честно говоря не ожидал !Есть мнение, что если у Вас помрет FC HBA - вам придется выбрасывать и сам сервер. Ибо статистика их отказов у нас стремится к нулю (если быть точным - 2 отказавших контроллера за 4-5 лет).
Но чесно говоря страшно представить, если таким "счастливчиком" окажусь я и жаль, что он весьма дорог.
с того, что одновременная поломка и массива на САТА и внешнего массива(который, как я понял, можно сказать вообще не ломается) намного меньше по теории вероятности, чем того же внешнего массива самого по себеC чего бы ? А вот то, что база при падении внутреннего массива встанет однозначно - это да. И восстановление ее в любом случае займет не 5 и не 10 минут - если Вам важен результат, конечно.
Все изменения не хранятся вечно в кэше, а еще и пишутся непосредственно в базу при коммите транзакции, так что утверждение "- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД", если речь идет о кэше SQL - явное заблуждение.При записи в файлы БД происходят следующие вещи:
- страницы SQL на запись кэшируются
- производится запись в лог без кэширования
- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД.
Напомнить, сколько Вы хотите иметь ОЗУ ? Вы готовы потерять несколько ГБайт информации в худшем случае ?
а чем перепроведение в 1С отличается от проведения? одна перепроводка- один коммит.массив под логами падает во время перепроведения документов, к примеру
я уже писал. данный спор я веду не для финансовой выгоды, а уже для просвещенияВы ради копеечной экономии (на которую я уже Вам обещал дать скидку) пытаетесь городить ежа - плохо управляемую, сильно разнородную дисковую подсистему.
Еще раз прошу поверить на слово - такие ежи никакой радости админу не приносят. Только геморрой.
a_shats
Согласен. Сейчас не могу найти память к серверу, приобретённому чуть более года назад. Посему и хочу избежать этот момент с новым сервером.Крайне отрицательно. Обычно приводит к проблемам.
Ок. Задам вопрос по другому. Если я захочу добавить ещё диски в массив, мне придётся докупать полку ?А смысл ? Диски надо считать не в полке - а в массиве.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Нет - но она ниже, чем у любого внутреннего. В силу дублирования критичных комплектующих.Dave251 писал(а): Да. так же как и при отказе массива с самой БД + лог. Хотя насколько я понял, по сказанному ниже, вероятность падения массива предложенного вами практически равна нулю ?
Никто не мешает установить 2х1-портовых контроллера вместо 1х2-портового, просто это еще дороже.обнадёживающая статистика. Честно говоря не ожидал !
Но чесно говоря страшно представить, если таким "счастливчиком" окажусь я и жаль, что он весьма дорог.
Повторюсь - внутренний массив в случае чего по-любому ляжет раньше, чем внешний. А сыпаться будет не в пример чаще.с того, что одновременная поломка и массива на САТА и внешнего массива(который, как я понял, можно сказать вообще не ломается) намного меньше по теории вероятности, чем того же внешнего массива самого по себе
Не заблуждение - а нормальный общепринятый алгоритм работы кэша записи. И не только SQL. Писать по commit просто слишком накладно, так писалось только во времена "плоских" таблиц (dbf и иже с ним). В логи - да, пишется сразу и мимо кэша. В базу - нет.Все изменения не хранятся вечно в кэше, а еще и пишутся непосредственно в базу при коммите транзакции, так что утверждение "- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД", если речь идет о кэше SQL - явное заблуждение.
Имелось в виду - массовое перепроведение документов за период.а чем перепроведение в 1С отличается от проведения? одна перепроводка- один коммит.
Это правильноя уже писал. данный спор я веду не для финансовой выгоды, а уже для просвещения
Апгрейд ныне - вообще штука довольно сомнительная для этого класса (ниже 4 сокетов) серверов. Слишком быстро (примерно раз в 2 года) меняются платформы.Согласен. Сейчас не могу найти память к серверу, приобретённому чуть более года назад. Посему и хочу избежать этот момент с новым сервером.
В массивы диски чаще всего докупаются именно полками. И ставятся - не купленные абы где и абы какие, а - только от вендора массива. Такой порядок - у всех "правильных" вендоров.Ок. Задам вопрос по другому. Если я захочу добавить ещё диски в массив, мне придётся докупать полку ?
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
Контроллеры, БП, FC-порты.Перечислите плиз, что именно дублируется.
на сколько ?
Предложение отправлю
Это теория. Практика - чтобы внешний массив ТАК навернулся, нужно что-то очень суровое по электричеству либо охлаждению.Тут в самом деле не помешала бы статистика. По ней можно было бы прикинуть
Подсчитать по 3м критериям. Статистика падений, скорость замены той или иной зап. Части и скорость восстановления БД.
1. Падение внешнего массива с логом и БД – замена зап.частей исключительно долгий процесс. Восстановление только с последнего бэкапа лога транзакций. Потеря данных максимальна.
2. Падение внешнего массива с БД, но массив с логом цел – Замена зап.частей исключительно долгий процесс. Восстановление с текущего лога транзакций. Потеря данных минимальна.
3. Падение внутреннего массива с логом, но внешний с БД цел – Замена зап.частей быстрая. Восстановление не требуется. Затраты времени минимальны.
Внутренний массив в таких случаях обычно не выживает. Внешний имеет шансы.
Вы знаете отличия физической структуры БД MSSQL от логической ?commit
An operation that saves all changes to databases, cubes, or dimensions made since the start of a transaction. A commit guarantees that all of the transaction's modifications are made a permanent part of the database, cube or dimension. A commit also frees resources, such as locks, used by the transaction.
И - еще раз процитируйте мне, пожалуйста, место из этого вот текста, где написано, что после коммита гарантированно выполняется запись данных на диск. Физическая. Запись в базу - да, согласен. Точнее - в кэш записи инстанса MSSQL. Я на скорую руку не нашел этой статьи в BOL, попозже, если найду - процитирую.
Именно, Ваш вариант приводит к бОльшему, а не к меньшему риску.именно. посему и пытаюсь оптимально собрать сервер. даже кое где увеличить риск. хотя риском, мой вариант, трудно назвать так....небольшое увеличение вероятности сбоя, с быстрым устранением.
А теперь расскажите, пожалуйста, что Вы собираетесь делать с этими 2-4 винтами после добавления.а я вот сомневаюсь, что в ближайшие год, полтора мне понадобится целая полка ! 2-4 винта возможно доставить понадобится.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Две однопортовки дороже на несколько сотен баков. Но, как уже сказали, кулоджиковские HBA - исключительно дубовая вещь. Они если и сломаются, то последними
Насчет надежности внешних дисковых - конечно не бывает идеальных систем. А чубайс, например, может нагнуть что угодно. Но по сравнению с внутренними массивами это просто небо и земля. Скажем так - если Вам не хватает надежности внешнего массива, решением может быть только два внешних массива, в зеркале
Насчет надежности внешних дисковых - конечно не бывает идеальных систем. А чубайс, например, может нагнуть что угодно. Но по сравнению с внутренними массивами это просто небо и земля. Скажем так - если Вам не хватает надежности внешнего массива, решением может быть только два внешних массива, в зеркале
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
подробнее можно ?FC-порты.
спасибо !Предложение отправлю
а как, на практике, внутренние САТА массивы (на хорошем железе) себя ведут ?Это теория. Практика - чтобы внешний массив ТАК навернулся, нужно что-то очень суровое по электричеству либо охлаждению.
Внутренний массив в таких случаях обычно не выживает. Внешний имеет шансы.
изучаю разные доки! начинаю склоняться, что вы правы по этому вопросуВы знаете отличия физической структуры БД MSSQL от логической ?
И - еще раз процитируйте мне, пожалуйста, место из этого вот текста, где написано, что после коммита гарантированно выполняется запись данных на диск. Физическая. Запись в базу - да, согласен. Точнее - в кэш записи инстанса MSSQL. Я на скорую руку не нашел этой статьи в BOL, попозже, если найду - процитирую.
БОльшему,но с меньшем временем восстановления. ну и ценником )Именно, Ваш вариант приводит к бОльшему, а не к меньшему риску.
например реплицирую туда базу для чтения....и пусть там отчеты делают. можно же в отдельный массив собрать и посадить на другой контройлер?А теперь расскажите, пожалуйста, что Вы собираетесь делать с этими 2-4 винтами после добавления.
а вот почему так? ведь железо оно и в Африке железо !Две однопортовки дороже на несколько сотен баков. Но, как уже сказали, кулоджиковские HBA - исключительно дубовая вещь. Они если и сломаются, то последними
Для этого у нас дизельный генератор...на всё зданиеНасчет надежности внешних дисковых - конечно не бывает идеальных систем. А чубайс, например, может нагнуть что угодно.
о да ! моя мечта.... :roll: но руководство не разделяет нашу точку зренияНо по сравнению с внутренними массивами это просто небо и земля. Скажем так - если Вам не хватает надежности внешнего массива, решением может быть только два внешних массива, в зеркале
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Их по 2 на каждом контроллере. При наличии между хостом и массивом свича и/или подключенных 2 портах FC с сервера при отказе интерфейса массив будет отдавать через другой интерфейс, если это явно не запрещено в управлении им.Dave251 писал(а):подробнее можно ?FC-порты.
Нормально ведут, но в здравом уме под сколь-нибудь серьезные нагрузки типа БД их не используют.а как, на практике, внутренние САТА массивы (на хорошем железе) себя ведут ?
Это основы, и не только для SQL. Теоретически и в RAID-контроллерах отложенная запись работает так же (практически - зависит от фирмвареписателей).изучаю разные доки! начинаю склоняться, что вы правы по этому вопросу
НеаБОльшему,но с меньшем временем восстановления. ну и ценником )
Можно. А дальше что делать будете ? Еще 2-4 винта докупать ? И ждать по 6-8 недель прихода этих винтов ?например реплицирую туда базу для чтения....и пусть там отчеты делают. можно же в отдельный массив собрать и посадить на другой контройлер?
Потому что сделаны компанией, имеющей просто неохватных размеров опыт производства таких вещей, сертифицированы под подавляющее большинство стандартов и приложений (что накладывает опять же некоторые требования), в них не применено ничего, требующее сверхчастот и сверхмощей.а вот почему так? ведь железо оно и в Африке железо !
Это до первого же чубайсопришествия или еще какого ЧП масштаба площадки :Dо да ! моя мечта.... :roll: но руководство не разделяет нашу точку зрения
-
- Advanced member
- Сообщения: 78
- Зарегистрирован: 21 сен 2005, 09:25
- Откуда: Иркутск
- Контактная информация:
ясно ! спасибо.Их по 2 на каждом контроллере. При наличии между хостом и массивом свича и/или подключенных 2 портах FC с сервера при отказе интерфейса массив будет отдавать через другой интерфейс, если это явно не запрещено в управлении им.
а по отказоустойчивости ?Нормально ведут, но в здравом уме под сколь-нибудь серьезные нагрузки типа БД их не используют.
я уже понялЭто основы, и не только для SQL. Теоретически и в RAID-контроллерах отложенная запись работает так же (практически - зависит от фирмвареписателей).
почему бы и нет ? мы всегда так делаем.Можно. А дальше что делать будете ? Еще 2-4 винта докупать ? И ждать по 6-8 недель прихода этих винтов ?
я думаю, что эта компания производит и сата железо, которое можно использовать для некоторых задачьПотому что сделаны компанией, имеющей просто неохватных размеров опыт производства таких вещей, сертифицированы под подавляющее большинство стандартов и приложений (что накладывает опять же некоторые требования), в них не применено ничего, требующее сверхчастот и сверхмощей.
К сожалению, видимо да!!! (Это до первого же чубайсопришествия или еще какого ЧП масштаба площадки
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 9 гостей