|
|
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
После сбоя на сервере данные представляют из себя следующее: часть записей таблиц нормально отобрадаются в режиме просмотра, а в части строк вместо данных отображается "ОШИБКА!". В чем причина этого и можно ли восстановить данные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 19:35 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Восстановить - сжать. "Ошибка" сгинет. Иногда (редко) надо в обратной последовательности (сжать-восстановить). Поэтому не забудь забекапить. Восстановить данные нельзя. Вернее, стандартными средствами точно нельзя, про существование нестандартных - ни разу не слышал (хотя тоже интересовался). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 19:49 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Восстановить данные не удалось. Пользоваться базой, в которой часть строк отсутствует не имеет смысла. Интересно, в чем причина такой фатальной ошибки? В том, что база использовалась по сети в момент сбоя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 20:27 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Именно так. Если базу не использовать - она будет жить долго и счастливо, и никогда не будет падать. А если использовать - то она когда-нибудь да умрет. Особенно если сервер ёк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 23:40 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Еще один существенный аргумент в пользу ADP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 00:07 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Это да. ADP понадежней будет. С другой стороны при нормально работающей сетке и одинаковых клентах (одинаковая база, одинаковый офис, все сервис паки) вероятность потери данных после падения базы очень мала. У меня за год такое один раз случилось, при том что с базой работают 150 человек и сервак время от времени таки падает. Не падал бы - совсем хорошо стало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 01:16 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
С помощью каких механиизмов обеспечивается большая устойчивость проектов ADP к воздействию сбоев на сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 10:32 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Тут Adp хвалят за устойчивость, что ни есть верно (ИМХО). Хвалить надо ядро MS SQL-сервера - а adp всего лишь интерфейс, к тому же подверженный таким же поломкам как и mdb. Только в случае использования MS SQL - ваши данные (при правильной организиции!) остануться в целостности (с достаточно высокой вероятностью), а интерфейс (adp) может накрыться медным тазом и более не ожить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 10:46 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Если на пальцах - то все очень просто. Большая устойчивость ADP (к потере данных) имеет место быть потому как у MS SQL с файлами данными работает всего один клиент - собстно СУБД, причем локально, а все остальные - уже через него. В случае mdb с файлами данных работает куча пользователей, причем через сеть. Если кто-то отвалится в процессе глобальных модификаций данных (индексов) - база ёк Для SQL сервера такое тоже может быть. Но редко. Например, в процессе записи чего-нибудь на диск кто-то топором перерубит SCSI-шлейф, а потом гвоздем нацарапает неприличное слово на пластине винта. Ну и куча других улучшайзингов в MS SQL С точки зрения сохранности кода пользовательского интерфейса (модули, формочки, отчеты) - что adp, что mdp одинаково может упасть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 10:53 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Ошибка в дисковой операции при записи именно этих данных. Обычно - после отключения (питания) и восстановления низкоуровневым (chkdsk /f). Лечатся не именно эти записи, но база: - берете (лучше бессбойную болванку с копиями структур таблиц, поскольку крах может быть и в чати системных записей) и высасываете туда данные. Данные из таблиц с ошибками можно вытянуть запросами методом проб и ошибок. (до ошибок - явным копированием, после - пытаться отловить условия запросов, не включающие диапазон ошибочных записей). Если нет хорошего образчика для болванки - таблицы с ошибками импортировать как "только структура", далее - по схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 12:04 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Резюме хотелось бы сказать. Восстановить базу можно практически на 90%. Для этого скачиваем программку MDB_REPAIR и она это дело заколбасит за две минуты :) А вообще такую ошибку выдает ядро при работе в сети когда одна ита же запись правится несколькими клиентами ( в основном через RECORDSET). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 12:30 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
2 alexkov А поподробнее можно? Аксес вроде всегда умел блокировки ставить, так что одновременная работа с записями не должна к падениям приводить. Просто юзерам сообщения об ошибках вывалятся, но это же не смертельно. Или я чего-то неправильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 13:39 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
На SQL сервере есть понятие "плана обслуживания базы". Там вы, к примеру, задаете каждый день делать полный баккап базы, каждый час баккап изменений, каждых 10 минут (можно й меньше) баккап лога транзакций. Кроме того (как и в Аксесе) данные и лог пишутся в разные файлы. Все это дает практическую возможность не только восстановить полностью базу, но и состоянием на ЛЮБОЕ время. Максимальная потеря данных в даном примере - за последние 10 минут при условии, что грохнулись оба файла и данных, и лога транзакций. И если вдруг выяснится, что вчера позно вечером вы вдруг при эксперементах грохнули какую-то таблицу, то и то легко востановить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 16:19 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Ну так и сделай каждые 10 минут бекап аксесовксой базы. "Живую" базу не рекомендуется копировать, но это лучше чем ничего. На случай падения (редкого при правильной организации) и потери данных (еще более редкая вещь) вытащишь оттуда пропавшие записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 16:24 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
2Лох Позорный А поподробнее можно? Аксес вроде всегда умел блокировки ставить Все ты правельно, толко некоторые пользуясь мастером основывают форму не на запросе, а на таблице. Вот тогда эта проблема и происходить. Но возможно такое когда один клиент открывает две разные формы основанные на одной и той же таблице и правит и там и там.(это видел сам на практике). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 17:59 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
"а в части строк вместо данных отображается "ОШИБКА!"." Кстати, такую же штуку я видел, когда я однажды снял копию с базы во время работы ( в сетевом режиме). Принес ее, стал смотреть, а там часть записей запорота...Так и не разобрались, в чем тут был прикол. Сошлись на том, что копии лучше с работающей базы не снимать. А тут, в совершенно других условиях - тот же прикол.(???) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 18:28 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
alexkov "Все ты правельно, толко некоторые пользуясь мастером основывают форму не на запросе, а на таблице. Вот тогда эта проблема и происходить. Но возможно такое когда один клиент открывает две разные формы основанные на одной и той же таблице и правит и там и там.(это видел сам на практике)." 1. Кому адресовано это сообщение 2. Если я правильно понял то, что Вы сказали, то Вы подразумевали следующее : Если в сетевой базе есть формы, основанные не на запросах, а на таблицах(серверных) и несколько пользователей одновременно вносят данные через интерфейс этих форм в эти таблицы, то это может привести к потере данных? Или я Вас неправильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 18:37 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
all Согасны Вы или нет с этим утверждением : "Если в сетевой базе есть формы, основанные не на запросах, а на таблицах(серверных) и несколько пользователей одновременно вносят данные через интерфейс этих форм в эти таблицы, то это может привести к потере данных?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2003, 15:57 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
2 Wara Не согласен. На отдельную таблицу аксес должен уметь накладывать блокировки не хуже чем на таблицы, входящие в запрос. Теоретически для аксеса паралельно запрос или таблица в качестве источника данных для формы. По крайней мере "Select * From Table1" не должно отличаться от "Table1". Моя практика с этой теорией пока не расходится. Я не нашел способов гарантировано (с высокой вероятностью) обрушать базу. Ну разве что в процессе восстановления базы снять задачу таск манагером . С живой базы лучше копию не делать. Чем активнее идет работа с ней - тем больше вероятность получить вместо копии фигню несогласованную. Вероятность падения увеличивается при различных конфигурациях софта на клиентских машинах. На одного клиента поставили MS SQL, через день снесли. Так в результате на клиентской машине изменились какие-то сетевые настройки (не помню какие), и при попытке работать с общей аксесовской базой через 5 минут приходилось запускать восстановление :(. Если на клиентах стоят раззные операционки, разные сервис паки, разные офисы (с разными сервис паками) - все это способно сказаться на надежности. При одновременной работе с базой в обычном режиме и через терминальные службы - восстановление раз в день. Хотя на этом форуме находятся люди у которых все работает нормально. Счастливчики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2003, 16:17 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Лох Позорный, Спасибо за информацию. Я тоже думаю, что от того, что форма основана на таблице, а не на запросе, база упасть не может. По крайней мере, в документации нигде на сказано, что формы должны быть основаны на запросах... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2003, 16:19 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
2wara >По крайней мере, в документации нигде на сказано, что формы должны быть основаны на запросах... Сказано. Но, конечно, не для того чтобы база не рушилассь, а для оптимизаци. Основовая источник формы на таблице, Акес создает в cвоих недрах сохраненые запросы вида ~sq_.... - это лишняя операции вполне возможно и может быть источником некоторых проблем.Запрос ~sq_.... ведет себя так же как и обычный запрос: будь это mdb или adp. Но главное для чего создаются запросы - это для ограничивания кол-ва возвращаемых записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2003, 16:36 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
Senin Viktor, Так все-таки, может от этого рухнуть база или возникнуть проблемы? Сам я прямо на таблицах формы не строю (даже если данные нужны из одной таблицы) - привычка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2003, 21:48 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
проблемы могут быть из-за блокировок записей. запись как правило не равна блокируемой области . поэтому блокируется несколько записей. одну редактирет один юзер другой не может сделать что-то. не видит карандаш. бывало такое.... самое оптимальное : считал запись запросом-из него заполнил поля - отредактировал- по кнопке сохранил./заполнил поля-по кнопке сохранил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2003, 22:02 |
|
||
|
Восстановление данных после сбоя
|
|||
|---|---|---|---|
|
#18+
2wara >Так все-таки, может от этого рухнуть база или возникнуть проблемы? Ну я же все написал. wara накати на себя сервис-пак Если сервис-пак не поможет, то так объясню: очень очень очень наврядли. Сохраненый запрос это тоже самое что и спец.запрос акеса (~sql_....). Храняться в одном месте, только и отличаются префиксом, да еще тем, что создаются в неявном виде. А от чего могут быть проблемы - ответ: от всего. Например, из-за хреновго вентилятора или потока нейтрино... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2003, 22:41 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32164522&tid=1681401]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 395ms |

| 0 / 0 |
