|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vitaly Polikarpov 2:461/132 23 Nov 2001 17:52:00
To : Vladimir Pavlikov
Subject : Re: Выбоp СУБД
--------------------------------------------------------------------------------
20 Nov 01 18:19, Vladimir Pavlikov -> Ivan Azmanoff:
>> YI> А если этот байтик накpоется в одном из dbf файлов бyдет намного
>> YI> легче?
В случае необходимости можно проверять валидность рекорда, но по хорошему это
должно быть ф-ией СУБД.
>> очень смешно... пpосто согласись, что веpоятность повpеждения одного
>> гигантского файла намного больше, чем повpеждение отдельного небольшого
>> файла. Точно так же, когда я пишy на дискетy большой файл, я pазбиваю
>> его на десяток мелких. Если повpедится один такой файл, я пpосто заменю
>> повpежденный файл.
VP> "Пpосто согласись", что база имеет один размер (примерно) что в одном
VP> файле, что в сотне. И вероятность повреждения одного большого файла
VP> вряд ли больше, чем одного из сотни меньших.
И зачем это клятi буржуiни выдумали какие-то там цилиндры, сектора/кластеры,
их низкоуровневую подмену ("втихаря", пока для этого есть возможность),
RAID-5 наконец ;)
Hыне, багодаря SMART и др. о хожднении "по граблям" под названием BadBlock
до поры до времени забывают, но там и других низкоуровневых хватает, при
которых носитель отказывает чаще всего целиком и надолго (до низкоуровневого
репайра, если данные того стоят), если не навсегда.
VP> При этом в любом случае повреждается база, и лечить ее методом
VP> "я пpосто заменю повpежденный файл" - очень плохое "решение".
Hе стоит так категорично, особенно, если база большая и время восстановления
критично, а RAID-5 ставить еще не целесообразно по экономическим или
скоростным критериям.
Эхотаг ведь используют не только в офисах, когда можно "девочек отправить
кофейку попить", но и для журналирования реалтаймовых или непериодических
процессов, задач управления, в т.ч. и в отнюдь не тепличных условия -
промконтролеры и тп.
А теперь вопрос в студию:
Какие СУБД поддерживают _автоматический_ контроль целостности хранимого
контента на уровне целостности рекорда таблицы после завершенной транзакции?
А также целостности SQL-запросов и других хранимых процедур?
"Соломку подстилать" в виде _своевременного_ бэкапа это круто, но:
Беру 30Mb mdb-шник, копирую в temp\, открываю hex-вьювом и:
В _цикле_ искажаю по несколько байт данных и запуская Асcess97.
И так 8 раз- пока мне не надоело, без единого "вопля" о:
-несанкционированой модификиции прикрытой паролем (от честных людей:) базы;
-необходимости бэкапа :)
Замечу, что результаты идентичны как для шифрованого, так для нешифрованого
mdb - только и того, что в последней поля открыты.
А вот и "счастье" привалило - A97 вывалился наконец-то по невозможности
прочитать рекорд при попытке зашифровать "подбитую" вдоль и поперек, без
привязки к полям базу.
И что дальше с ней делать? Писать софтину для разбраковки данных, или сразу
"в морг"? ;)
Так на каком цикле "искажений" _рабочих_ (а не тестовых!) данных мы ныне
плывем? ;)
По какой рез.копии делать, и когда, собственно, начинать бэкап? ;)
Заодно, и кто должен этим озадачиваться: админ с местами _уже_ искаженной,
местами устаревшей резервной копией, когда (СУ)БД ну уж "савсэм
прижмурилась"(c), или все-же недоделкины из простоквашино, стучашие пятками
в грудь какие они крутые прогамеры, позволяющие в СУБД
с _интегрированым_хранением_ подменить _втихаря_ не только текст,
но и хранимые процедуры, ссылки на ресурсы и тп. со всеми вытекающими :(
Благо хоть А97 юзается как записная книжка и не более..
Что было-бы в случае офисного/банковского/технологического применения,
когда за искаженными данными будут стоять финансы или глюкнувший критичный
техпроцесс - no coment :(
Это одна из причин, по которой от использования СУБД для хранения критичных
данных отказался 5 лет назад, в пользу обычных FS, направив усилия на
создание ИПС, работающей с "сырым" plain-text, а не индексироваными
массивами, требующими актуализации индекса в случае модификации данных
(читай постоянно).
Так и родился с год назад поисковый сервер, обрабатывающий очередь заданий
каждое до Int(255/N_СodePage) масок поиска за один проход по логич.дискам,
согласно заданной стратегии с поддержкой 16 типов архиваторов.
До совершества ему далеко (не все фишки типа автореферирования реализованы),
но его и делали не программисты, а электронщики под свои нужды ;)
Vitaly Polikarpov
---
* Origin: INTELLECT group (2:461/132)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
