|
|
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Люди, помогите пожалуйста. Как в Access'е можно решить проблему резервного копирования ? Просто у меня самого база падала с летальным исходом. Сейчас я разработал БД и за нее мне готовы заплатить деньги. Но работодатели очень чувствительно относятся к возможной потере информации, и я их понимаю. Поэтому прошу советов. Причем резервное копирование надо делать довольно часто, приблизительно раз в 20 минут :( Если в Аксесе это сделать невозможно, то подскажите в какую сторону копать, чтобы обеспечить надежную защиту информации от краха. В сторону SQL Server ? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 19:29 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Тоже хочу сделать такую штуку. Склоняюсь к мысли, что надо просто хранить в основной базе пути на файлы с данными и пути , где будут хранится backup. А дальше либо сделать кнопку "Сохранить копии БД" и пусть ответственные ее периодически нажимают, либо автоматически сделать, чтобы соотв. файлы через определенное время копировались с одного места на другое. Может еще извратиться и сделать "Восстановление" по последнему backup, те если база упала, нажимаем куда-то, процедура смотрит дату последнего Bup и говорит "Восстановить данные на такое-то время?", елси да, то переписыввает файлы из bup в основной каталог (каталоги). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 21:01 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Проще всего через назначенное задание в Windows запускать Arj. Через каждые 20 мин. MDB закрывать при этом не надо, пусть пользуются в процесе архивирования.Почти 100% восстанавливает БД програмка JetCU40. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 23:45 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Без SQL это сделать трудно, очень трудно. В SQL no problem. MDB закрывать при этом не надо, пусть пользуются в процесе архивирования. Не так все просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 00:00 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Самое оптимально создать отдельный батник (лучше прогу - с красивой заставкой), которая в момент запуска проверяет работает ли кто0нибудь с данными, если нет - то копирует, копирует и интерфейс, а затем запускает базу. Копировать базу в момент работы не очень хорошое решение. Тут уже были топики по этому поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 09:51 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Копировать базу в момент работы не очень хорошое решение Скажем честно - это очень плохое решение. Даже преступное. Никогда нельзя делать бекап с базы в процессе работы. Получится не резервная копия, а фигня какая-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 10:05 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
При таких требованиях к надежности без SQL Servera врядли можно обойтись. Ведь эксплуатация, насколько я понял, будет непрерывная, не будут же пользователи прекращать работу каждые 20 минут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 10:10 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Да, всё грустно. :( Эксплуатация действительно непрерывная. Одно радует, моя база написана исключительно с использованием ADO и поэтому переход на SQL Server будет не таким болезненным. Но вот еще хотел бы поинтересоваться. В одном из писем на форуме, как раз на тему надежности mdb человек под ником Latuk писал: При работе с файл-сервером рекомендую: ....... {пропускаю} 3) постараться пользоваться запросами через Execute по максимуму отказавшись от рекордсетов , там где это не получается открывать рекордсеты "толькочтение". И это пожелание меня очень насторожило, поскольку я везде где только можно использую рекордсеты, причем в большинстве случаев _не read-only_. Неужели это опасно ? А к SQL Server'у этот совет тоже относится ? Я в MSSQL только начинающий и хотел бы задать такой чайниковский вопрос. Вот с mdb под резервным копированием мы понимаем просто копирование файла mdb. А под SQL Server'ом это можно организовать попроще, т.е. не копировать всю базу целиком а реплицировать в старую резервную копию измененные записи ? По идее это будет занимать гораздо меньше времени. Ведь зачем копировать, например, тысячи строк данных о покупателях по новой, когда 99.99% из них не изменяются, а изменилась какая-нибудь одна запись. Можно ли реализовать такое ? Спасибо всем за ответы! У меня теперь два любимых форума: SQL.RU и HIPROG.COM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 10:40 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Для начинающих (и не только) в Sql как раз проще сделать резервное копирование базы (причем стандартными средставми самого сервера), а репликация - куда более сложный процесс, требующий гораздо больше знаний и навыков. Причем делать резервное копирование на sql не нужно каждые 20 минут (если база летит, то в основном при проблемах с "железом" - у меня за 4 года на нескольких серверах несколько баз ни разу не летели). Поэтому достаточно выполнять копирование каждую ночь. А еще лучше не только копирование, а полное обслуживание. Думаю в факе об этом можно почитать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 10:55 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Если речь только о резервном копировании , а с быстродействием проблем нет и не предвидется и базу переписывать влом , то можно извратится вот так : 1) Создать базу на MSSQL с таблицами структура аналогичной MDB 2) сделать в базе вьюхи на таблицы в MDB как внешний источник 3) написать процедуру , которая будет копировать содержание таблиц MDB (можно просто удалять /добавлять все записи , если будет тормозить то добавить логики и удалять добавлять только измененные) 4) Написать job , который будет запукать процедуру копирования и бакапить полученную SQL базу раз в N минут. 5)Написать ХП заливающую в MDB содержание SQL базы (восстаноление в случае сбоя) Если сервер будет стоять на той же машине , что и MDB то все будет довольно быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 15:32 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
>т.е. не копировать всю базу целиком а реплицировать в старую резервную копию измененные записи Если реч о базе MSSQL то там это стандартная функция бакап делится на две части 1)бакап базы целиком 2)бакап лога т.е . изменений произведенных с момента предидущего полного бакапа причем в одном файле можно накапливать несколько версий бакапов и востанавливать с любого из них по выбору. бакап лога используется в основном в тех случаях когда полный занимает слишком много времени (есть много других специфических методов использования лога ,но они к этой теме не относятся). Например у меня база 70 метров полный бакап 8 сек Бакап лога каждые 15 мин <1 сек если сделать бакап с накоплением версий , то можно будет легко востановить базу не только в последнем состоянии но и с отступом на 15 ,30 , ... мин.(можно и в ручную откатывать транзакции но к резевному копированию это не относится) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 15:49 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
"делать резервное копирование" .. "не нужно каждые 20 минут" А если база слетит в конце дня после того, как туда весь день вносились массовые изменения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 15:52 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
"делать резервное копирование" .. "не нужно каждые 20 минут" А если база слетит в конце дня после того, как туда весь день вносились массовые изменения? Я же говорю SQL - это не MDB. Если и слетает, то только в результате проблем с "железом". Если стоит вопрос о надежности данных, то: - к серверу (компьютеру) физически ограничивается доступ, он устанавливается в отдельную закрываемую комнату с кондиционером и мощным ИБП. - на сервере устанавливается райд-массив А что касается надежности самого SQL-сервера, то я уже говорил за 4 года работы у десятков клиентов ни разу не было сбоя из-за софта, только из-за "железа". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:00 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
incold, 1. Спасибо за ответ про OLAP - кубы 2. SQL - сервер стоит далеко не у всех еще пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:10 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
ребят, а у меня сделао так: создаю новую базу (имя - префикс+дата+время), прохожусь циклом по всем таблицам и запросом "выбрасываю" их в новую базу. даже при работающих пользователях. что плохого? записи которые вводятся - ещё не зафиксированы и я так понимаю не будут перекинуты в новую базу. вобщем, вопрос: какие могут быть проблемы при таком архивировании? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:13 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Какие проблемы? Несогласованность данных и/или нарушение ссылочной целостности непример. 1. Твой архиватор отсканировал и переписал данные из Таблицы1 2. Пользователь в транзакции (да или даже без нее) добавил/изменил записи в Таблице1 и Таблице2. Изменения взаимосвязаны. 3. Твой архиватор отсканировал и переписал данные из Таблицы2 И получил ты опять таки полный бред вместо резервной копии. Такое решение ничуть не лучше простого копирования mdb файла (если не рассматривать то, что при простом копировании база вообще в рухнувшем виде скопироваться может) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:29 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
хорошо, а если сделать при начале архивирования пометку АРХ. и скажем перед выполнением транзакции или записи из формы (при открытии новых форм просто поставить в цикл и вывести окошко для других пользователей, мол подождите) ждать пока пометка не снимется, а потом продолжать. можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:56 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
А может заблокировать все таблицы на период этого "резервного копирования"?. Тогда никакой несогласованности в данных не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:09 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
А может просто не е%ать мозг и всех из базы выгнать? Работать то они все равно не могут 2 wara Если попытаться блокировать таблицу с которой кто-то работает - на фиг пошлют тебя (архиватора), а не того кто работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:12 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Лох Позорный А что, нормально. Мне больше всего по душе следующий вариант:3 раза в день запускается процедура, появляется сообщение (у каждого): "Внимание, немедленно закройте все формы в приложении ...Будет производиться резервное копирование. Все несохраненные данные будут утеряны". Потом у каждого загорается прогресс-бар с обратным отсчетом времен: "До начала резервного копирования осталось ...Все таблицы будут заблокированы". Потом все таблицы блокируются, появляется сообщение "Идет резервное копирование. Все действия с базой бессмысленны". После окончания появляется окно "Резервное копирование закончено. Можете продолжить работу"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:27 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
2 ЛП... да не парить мозги оно то проще =) выгонять пользователей не вариант. а вот приостановить их работу. почему нет? =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:36 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Все действия с базой бессмысленны Это - в заголовок приложения. И на рабочий стол каждому пользователю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:36 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
2 wara Интересно а какая ж это процедура будет выдавать такое сообщение на клиента? Этот вопрос (передачи сообщений на клиента с сервера) уже давно обсуждается. В предложенном варианте придется на клиенте опрашивать какой-то флаг в базе. Если юзеров 5-10 еще нормально, а если 100-200, да еще каждую минуту...тарффик на сеть неоправданный. К тому же, а если пользователь начал редактировать запись (т.е. в данный момент она блокирована) и пошел покурить, а в этот момент резервное копирование...??? Выводы: на Access (MDB) сделать надежное резервное копирование базы данных в момент работы программными методами - нереально. Либо переходить на сиквел. Либо применять административные меры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:38 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
=)))))))))))) Все действия с базой бессмысленны фраза.... шикарная... =)))))))))))))) 2 incold сделать надежное резервное копирование базы данных в момент работы программными методами - нереально. но попытатся можно?.. ну не реально выгнать операторов.. а данных вводится много за короткий промежуток времени... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 17:56 |
|
||
|
Резервное копирование в Access'е
|
|||
|---|---|---|---|
|
#18+
Переходить на сиквел только из-за проблем резервного копирования? Все равно что на танке в булочную ездить. Мужики, вы чего? У меня база больше чем за год один раз упала так, что не поднялась потом. Один раз за год пришлось восстановить базу из бекапа. Если у вас падеж баз регулярный - так причину этого найдите и устраните. Если база падает чаще чем раз месяц (хотя бы раз в неделю) - это уже болезнь. Как и при любой болезни надо устранять в первую очередь причину, а не последствия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 18:00 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32173018&tid=1680148]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
86ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
96ms |
get tp. blocked users: |
2ms |
| others: | 253ms |
| total: | 491ms |

| 0 / 0 |
