Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Какая СУБД считается самой устойчивой в смысле восстановления после сбоя? Накрылаь база в Access при сбое сервера, хочу изучить вопрос прехода на что-то более надежное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 20:31 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
А что такое сбой? сервер перезагрузился или повреждение базы при котором дальнейшая нормальная работа невозможна? к первому наверное все устойчивы(транзакчии пропадут ну и х. с ними) а вот со вторым даже не знаю. Текстовый файл надежнее здеся будет :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 20:40 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Что-то сбойнуло на серваке (скорее всего винт перегрелся или что-то типо того). После этого часть записей оказалась испорчена. Процедура "восстановления" данных только "причесала" загаженные данные, но не восстановила их. (Все это происхожило в MS Access). Причем 1С как-то сумела свои плоские файлы восстановить, а Accees - нет. Тепрерь все ходят и говорят, что 1С - это круто, а наша прога - туфта. Какая СУБД более устойчива к подобным неприятностям? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 21:43 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Ну наверное та, которая сама может выполнять резервное копирование по расписанию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 05:54 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Мне почему-то кажется, что если будет сбой на винте, то данные гарантированно иожно восстановить только с другого винта ака бэкап. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 06:27 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Как минимум субд должна уметь делать горячее резервное копирование. Это конечно поможет, но изменения с последнего бакапа всё равно будут потеряны. Если потеря данных очень нежелательна то в субд обязан быть механизм архивирования журналов транзакций. В оракле это механизм ARCHIVELOG. При правильной настройке которого, в случае повреждения базы, максимум что теряется это изменения в бд за последние несколько минут работы. Этот же механизм даёт возможность восстановить состояние база на нужный момент времени в прошлом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 09:45 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Интересно то, что не все данные накрылись (это было бы не так обидно), а только часть, причем та часть, что, по всей видимости, использовалась клиентами (мне кажется, испортились только те строки, из которых были выбраны данные во время сбоя на клиенте). Если это так, то СУБД то же внесла свою лепту в этот фатальный результат (те данные, что не использовались, остались целыми) - наверное, должен быть механизм сохранения выбранных строк при сбое...а затем по этим данным должен быть механизм восстановления... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 10:39 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
наверное, должен быть механизм сохранения выбранных строк при сбое...а затем по этим данным должен быть механизм восстановления... Никакая СУБД не занимается процессом физической записи данных на носитель. Это операции уровня операционной системы и для этого есть специально предназначенные устройства. СУБД вообще может ничего не знать о том, где и как на самом деле физически размещены ее данные. Поэтому если ваш контроллер диска или сами диски сошли с ума, то единственное, что может может попытаться сделать СУБД - это на основе знания логической организации своих данных попытаться определить насколько эти данные уцелели. Таким образом защита от потери данных - это не только задача СУБД. Это комплексная задача. И любую СУБД можно сделать неработоспособной в принципе за несколько секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 10:57 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
И любую СУБД можно сделать неработоспособной в принципе за несколько секунд. Ес-сно... Булыжник - орудие пролетариата... Хрясть по серверу!!!... Хрясть по бэкапным ленточкам!!!.... Какая СУБД самая надежная??? ;о))) ЗЫ. А вообще-то вопрос был про программный сбой на сервере. От физического ничего не спасет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 14:13 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Ну в первом вопросе про природу сбоя ничего написано небыло. Зато потом >скорее всего винт перегрелся или что-то типо того Так что это уже железо. А тут без бэкапа уже не спасьтись, только на удачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 14:58 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Кто-нить ответит парню по делу?! И на адрес посмотрите: п.Андреевка - какой на х. оракл?!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 15:16 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Отвечаю по делу. Firebird. И бэкап каждый час простым копированием. и каждый день при помощи gbak На другой винт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 15:20 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
2Циничный Кот Ес-сно... Булыжник - орудие пролетариата... Хрясть по серверу!!!... Хрясть по бэкапным ленточкам!!!.... Какая СУБД самая надежная??? ;о))) MS SQL базу могу "убить" (не удаляя ничего!) скриптом из 4 команд. А вообще-то вопрос был про программный сбой на сервере. От физического ничего не спасет А что есть программный сбой на сервере? Баг ядра СУБД ? - это вряд ли можно предотвратить Использование такого бага вопреки предупреждению? - вина как минимум наполовину на создателе кода Баг клиентского кода ? - вот тут уж извините никакие ухищерения на уровне СУБД не помогут. Ибо один дурак такое может придумать, что и сто мудрецов не разгребут. Запрет ядром СУБД возможности доступа к системным/простым данным напрямую ? - "лючки" всегда остаются. Да и людям свойственно производить утечку информации. Организация системы восстановления сбоев ? - Вот это более менее здравая мысль. Т.е. транзакшен логи, контрольные суммы, чередование данных и тп. Только главное чтобы такой механизм не стал обузой. Т.е. не надо требовать от СУБД всего - иначе это будет уже не СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 16:17 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
2alex_k А зачем бекап каждый час? Сделать зеркало на другой винт. И делать бекап раз в день-неделю. И ждать, пока полетит контроллер :-) Или одновременно оба винта посыпятся. По другой причине, имхо, данные в IB не потеряешь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 16:49 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Glory, код в студию! Roman Ignatiev, я поспрашиваю в других конфах так ли это. Сильно подозреваю что Вы лукавите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 17:25 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
>А зачем бекап каждый час? Сделать зеркало на другой винт. А это от программного сбоя. А то отзеркалируются косяки и на другой винт и не буде щастя :-) А копировать лучше в разные места если база маленькая :-) а если большая то лучше не копировать так часто а хотябы раз в день. А еще можно написать клиента(для большой базы) который будет фетчить важные данные за последние 10 минут и в файл складывать. Чтобы потом с точностью до десяти минут восстановить от последнего бэкапа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 18:57 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
2 Pavel На ваш страх и риск Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 19:05 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
На мастере пробовать не советую - сервер падает практически тут-же, и без ребилда мастера никуда уже не ходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 20:46 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
>Firebird. \r >И бэкап каждый час простым копированием.\r \r Как мы уже выяснили вот тут: /topic/29612 В IB "простое копирование" "по горячему" "чревато боком". А каждый час базу останавливать не будешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 09:02 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Ну прогнал я чуток :-) Вообще на маленьких базах с маленькой нагрузкой можно, мелкому бизнесу подойдет. Ну а так лучше по ночам :-) и базу проектировать с возможностью репликации в альтернативную... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 09:28 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
2Pavel Не лукавлю. Говорю на основе собственного опыта. P133 Win95+32Мб памяти. Установлен офис и IB, а поскольку это было в области, то электричество пару раз за неделю неожиданно отключалось :-) Пользователей было около 5. Естественно, пользователи и не подозревали, что там IB установлен. В результате - более чем за 300 дней ни одной ошибки в базе (на диске - были), все работает, вообще без обслуживания. Работало бы и дальше, да я приехал проверить :-))) Что еще нужно? "А каждый час базу останавливать не будешь." И не надо, бэкап делается на ходу, как положено. Если сервер не хочется загружать, технология известна: останавливаешь IB, меняешь расширение у shadow, переносишь этот файл на другой компьютер, запускаешь сервер IB. На другом компьютере спокойно делаешь бэкап. Были у меня и потери, конечно, но все из-за физического повреждения диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 11:08 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
to Roman Ignatiev А у меня знакомые разрабатывавшие приложения под IB, вспоминали как базы просто сыпались не понятно из зачего, нарушалась логическая структура баз, то какой то хитрый запрос убивал наповал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 12:17 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Ну что могу сказать? Должны присутствовать две вещи: forced writes (не надо предоставлять системе самой писать в файл когда ей захочется) ну и драйвер руки.sys нужен, разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 13:10 |
|
||
|
Самая устойчивая к сбою сервера СУБД
|
|||
|---|---|---|---|
|
#18+
Не знаю как сейчас, а раньше IB действительно имел дурную привычку рушить логическую структуру БД, и force write и кривые руки тут абсолютно были не при чем. При частом выполнении сложных запросов с большим набором данных периодически рушились базы. Причем интересно, что IB сам этого не различал и пару раз я натыкался на такую ситуацию, что select * from table приводила к полному зависанию IB, а при прогонке validation выяснялось, что эта таблица где то по середине имела запорченные кластеры, что вообще не понятно, так как данные на этих кластерах были записаны сто лет назад и никогда больше системой не изменялись. После работы с такими чудесами у меня стойко сформировалось недоверие к надежности хранения данных в IB и его производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 14:54 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32165225&tid=1553811]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 216ms |
| total: | 366ms |

| 0 / 0 |
