FleX_2004 писал(а):а зачем тебе ДЛЛ ка? непойму... работа с файлом проще некуда... 10 строк кода + забитие нулями 3 строки итого=13 строк.... что в прогу поместить нереал???
Andrey Fedorov писал(а):У него смысл навроде: программа вытаскивает из запароленного архива некие данные (например mdb-шку) и эксклюзивно работает с ними. По завершении она должна уничтожить эти файлы. Проблема в том что продвинутый юзер может прибить собственно программу так что она не сможет произвести уничтожение и данные будут ему доступны...
hFile=CreateFile(FILE_NAME, GENERIC_ALL, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0)
CloseHandle hFile
DeleteFile FILE_NAME
ANDLL писал(а):Чего-то я не вник...
1. Дешефруем(в файл FILE_NAME)
...
uhm писал(а):Таки если это БД, зачем вообще чего-то шифровать? Создать пользователя с паролем, все запросы в программе делать от его имени... А за безопасность пусть сама БД отвечает. Или я чего-то не понял?
uhm писал(а):Таки если это БД, зачем вообще чего-то шифровать? Создать пользователя с паролем, все запросы в программе делать от его имени... А за безопасность пусть сама БД отвечает. Или я чего-то не понял?
FleX_2004 писал(а):я знаю! я знаю! спросите меня!!!!
А попробуй дорогой друг выгружать расшифрованное это дело не в файло а в память, а...
!Viper! писал(а):то есть зачем огород городить, если хорошо реализованная база данных может сама следить за своей безопасностью.
FleX_2004 писал(а):2MeMBus нда.... сложная задачка...... думаю вариант написать свою БД... со встроенным шифрованием ТВОИМ.... все что могу посоветовать.....
alibek писал(а):Но по любому, локальный доступ и безопасность понятия несовместимые
Igor_123 писал(а):alibek писал(а):Но по любому, локальный доступ и безопасность понятия несовместимые
К сожалению это мало кто понимает, но все хотят именно так
А о том что под базу выделить ещё и сервак отдельный, это вообще считаеться преступлением (КАЗЛЫ!!! )
%subj% - INFO: началась жизнь после 10GB
Привет всем. Вот вам чтиво на выходные.
Собственно [%subj%]
Тут года два назад спрашивали, какой объем информации хранят в базах с
"объектной" структурой "имени Котляревского"
На текущий момент у нас в корневых таблицах объектов
OBJECT: 2320509 записей (люди, организации, паспорта, адреса, объекты
недвижимости ...)
DOCUMENT: 4131889 records (всякие документы)
Новая страшная древовидная таблица ассоциаций DOCUMENT и OBJECT
STD_DOC_OBJ: 6724737 records
записи STD_DOC_OBJ тоже оформлены в виде объектов Кстати, эта таблица -
наше избавление от XML о котором, если кто помнит, я тут писал в
январе-феврале 2002 года.
После последней реорганизации и чистки структуры в базе осталось 140 таблиц.
К сожалению, эталонная конструкция структуры еще не получена - OBJECT и
DOCUMENT нужно объединять. Вот как тут не вспомнить убогость IB5.6
-------
Репликация:
За год восстановили около 12.5 тысяч пакетов
Таблица связей локальных и внешних идентификаторов - 14052763 records
формально это число можно принять за общее количество объектов основной БД
на 14 сентября 2004 года и 18 филиалов до текущего момента. Общее число
объектов на текущий момент (судя по другой базе, куда только заливают) -
около 18 млн. 4млн - это, скорее всего, число объектов созданных в рабочей
базе с 14 сентября 2004 года.
Среднее число изменений в рабочей базе центра за сутки - 13-15 тыс. Что
вполне согласуется с размером журнала изменений базы - 3556562 записей за 9
месяцев.
По объемам центр за сутки дает как минимум столько же сколько все филиалы.
Если строятся отчеты (результаты сохраняются в базе), то изменений
получается гораздо больше.
Размеры филиальных пакетов до 100KB - присылаются по почте.
Восстановление пакетов выполняется как правило по ночам, но очень часто
заливают и днем, при наличии активно работающих пользователей.
Репликация пока эксплуатируется в однонаправленном режиме.
Из интересных моментов - с помощью репликатора в январе этого года мы из
двух баз Елецкого филиала (город и район) сделали одну. Народ парился в
отдельными базами в течении 5 лет.
-------
Сбои узловых баз.
В июле 2004 года накрылась база одного филиала - восстанавливали из пакетов
репликации, которые прислали из этого филиала. 2 дня простоя филиала.
В октябре 2004 года - накрылась база еще одного филиала. Сливали данные
филиала из рабочей базы. Простой узла, по моей злобе душевной, составил 3
недели. В качестве оправдания было то, что мы провели тотальную ревизию
алгоритмов заливки данных. В реальности, это был филиал который "обучал"
пользователей других филиалов решать проблемы с помощью кнопки "reset".
В обоих случаях - данные заливались в пустую БД. Базам назначался новый
идентификатор.
Третим сбоем можно считать когда в указанном выше первом филиале 26 апреля
2005 перевели серверные часы на месяц вперед и вводили данные в течении
15-20 минут. Чернобыльцы, блин. "Чинили" оригинал и базы данных в центре.
-------
Тут я сделаю лирическое отступление - интересно какого размера гемморой
будет у людей, которые будут обслуживать объединенную БД по всей России?
Если такую смогут построить, конечно.
-------
Обслуживание.
У нас на сервере обслуживается 2 базы - рабочая (10GB) и дублирующая (чуть
меньше 9GB, в неё пишет только репликатор). Разница - это лог действий
пользователей.
Ночной процесс начинается в 22:00 заканчивается около 6:30. в общем -
время в притык.Сначало параллельные BR обоих баз - заканчиваются в 4 часа
ночи, потом идет
архивация старых баз и полученных бакапов + копирование архивов бакапов на
резервный сервер.
После BR (параллельно архивации) запускается резервирование изменений
рабочей базы. Потом запускается восстановление пакетов обновлений в базы.
Формально, у нас в запасе есть еще около 4-5 часов (можно раньше начать и
позже закончить). Без ночного BR база более менее работоспособна в течении 3
суток. Вообще говоря BR-это единственный знак внимания, который оказывают
FB. В остальном он работает в режиме, о котором пишут в рекламных
проспектах - на него просто напросто забивают. Конкретного человека,
которому поручено администирование у нас нет.
По вечерам руками убиваются зависшие процессы.
От дневных бакапов рабочей БД мы отказались - после того насилия которые
были учинены над базами во время последного обновления в мае этого года,
действия пользователей - это детский лепет. Короче, вера в FB 1.5 стала
твердой как курс партии. Тьфу-тьфу-тьфу
---------
Сервер базы данных FB 1.5.2 классик
OS: WIN2003
Железо - два ксеона 3.2, 12GB, разделы под базы и бакапы на RAID5 на пяти
сказевых винчестерах. Машину заказывали у аквариса. Машина, реально
навороченная, как раз для таких криворуких как мы - возможно из нее можно
выжать раза в два больше чем она дает, но - смотри выше про
профессионального
администратора.
За 9 месяцев эксплуатации этого сервера только один раз вышел из строя один
из винчестеров рейда. Потом его переткнули и он восстановился. Пользователи
ничего не заметили, а мы чуть от страха не померли. Я был без памперсов
---------
Реально, конечно, у нас тут вагон проблем связанных с тем, что многие вещи
заложены с избытком (ибо страшно - никто не знает, как это все должно
выглядеть на самом деле. А кто говорит что знает - врет). И скорее всего
основная проблема в том, что мы сами с трудом можем переварить сложность
управления такими проектами. Многие идеи проходят наскозь без шанса быть
освоенными. Катастрофически не хватает _нормальных_ людей.
Но тем не менее, судя по процессам протекающим в нашей предметной области
(а, ну да, я про регистрацию сделок с недвижимостью) мы на верном пути
Коваленко Дмитрий.
www.ibprovider.com
PS. Пользуясь случаем, передаю привет Еманову
PSS. А так же всем, кто пытается хоть что-то улучшить в этом мире )
Сейчас этот форум просматривают: SemrushBot и гости: 68