Неможливо створити новий файл журналу, оскільки базі даних не вдається записати на диск

Щоб дізнатися більше про дану подію, виконайте одну або кілька з таких дій.

Це попередження означає, що не вдалося створити новий файл журналу, так базі даних не вдається записати на диск файлів журналу.

Ця подія може реєструватися, якщо даний диск призначений тільки для читання, переповнений, неправильно налаштований або пошкоджений. Причина залежить від числа помилок в секції опису даної події. Нижче перераховані коди найбільш поширених помилок для події 413.

Помилка -1032 = 0xfffffbf8 = 4294966264 = Jet_errFileAccessDenied = Неможливо отримати доступ до файлу - файл заблокований або використовується. Інший процес заблокував файл. Можливо, модуль антивірусної перевірки помилково помістив файл в карантин, або процес архівації тимчасово викликав відмова в доступі. Можливо, програма резервного копіювання плоских файлів або антивірусна програма зайнята обробкою сховища Exchange, каталогів з файлами бази даних служби реплікації сайту або диска M. Ця помилка також може виникати, якщо дозволів доступу до папки з файлами банків повідомлень або служби реплікації сайту, недостатньо для правильного функціонування баз даних. Можливо, застаріли драйвери обладнання.

Помилка -1811 = 0xfffff8ed = Jet_errFileNotFound = Файл не знайдено. Ця помилка може бути викликана відсутністю файлу журналу або іншими причинами. Наприклад, поточний файл журналу (наприклад E00.log) може мати підпис, не збігається з журналом і базою даних. Інша причина виникнення помилки -1811 полягає в тому, що, можливо, база даних Exchange і файли журналу поміщені в мережеве сховище, що не підтримується. Крім того, можливо, пошкоджений файл контрольної точки або стався збій самого диска журналу. Поточний файл журналу міг бути захоплений і знищений антивірусною програмою, що працює на сервері. Також виникла проблема із збереженням тимчасового файлу журналу для групи зберігання (наприклад, e00tmp.log). Можливо, пошкоджений сам тимчасовий файл журналу.

Помилка -1022 = 0xfffffc02 = 4294966274 = Jet_errDiskIO = помилка вводу / виводу для диска. Помилка -1022 - це загальна помилка, яка виникає, коли з-за проблеми з введенням / висновком на диску Exchange не може отримати доступ до запитуваної сторінці в базі даних або до контрольного файлу. Можливо, стався збій диска або контролера і втрачений доступ до всього диску (іноді тимчасово). Можливо, програмне забезпечення контролера або мікропрограма застаріли. Перевірте наявність в системному журналі повідомлень про помилки введення / виводу або диска, що сталися приблизно в один час з подією 413. Ця проблема може виникати через неправильне шляху до контрольного файлу (такого як E00.chk), що може бути викликано збоєм диска.

Для усунення цього попередження виконайте одну або кілька з описаних нижче дій:

Перевірте цілісність файлової системи.

Перевірте наявність в системному журналі пов'язаних записів.

Перевірка та зміна властивості дозволів на доступ, а потім запишіть обсяг вільного місця на диску.

Перевірте диск і файл журналу, в який виконується спроба запису.

У разі помилки -1811 переконайтеся, що антивірусна програма не виконує жодних сховище Exchange і каталоги баз даних служби реплікації сайту. Переконайтеся, що на диску файлів журналу досить вільного простору.

При помилку -1022 переконайтеся, що диск файлів сховища Exchange доступний і що шлях до файлів сховища Exchange вказано правильно. Якщо це так, виконайте команду chkdsk / f / r. Якщо цю проблему не вдалося вирішити за допомогою засобу Chkdsk, перевірте дозволу на структуру папок сервера Exchange. Переконайтеся, що система має повний доступ до сервера Exchange (шлях установки Exchange) і всім підпапках на кожному розділі з даними Exchange. Якщо все одно не вдається підключити бази даних, проведіть діагностику встановленої на сервері Exchange антивірусної програми, яка виконує перевірку на файловому рівні (якщо є). Перевірте наявність в системному журналі помилок введення / виведення або диска, що сталися приблизно в один час з подією 413. Перевірте і виправте шлях до контрольного файлу (наприклад E00.chk).

Якщо після усунення основної причини цілісність бази даних буде порушена, виконайте відновлення з оперативної резервної копії. Якщо допустимої резервної копії не існує, можна відновити цілісність бази даних за допомогою функції жорсткого відновлення (/ p) службової програми Eseutil. Запускайте isinteg -fix. поки не будуть виправлені всі помилки, підключіть базу даних, а потім перенесіть її в нову порожню базу даних за допомогою функції переміщення Перед цим слід зробити резервну копію всіх файлів сховища Exchange в групі зберігання (файли * .log, * .edb і * .stm ).

Схожі статті