Отсутствует файл ps udb

Обновлено: 02.07.2024

Если файл .UDB известен Вашей системе, то открыть его можно двойным нажатием мышкой или клавишей ENTER. Эта операция запустит ассоциируемые с файлом .UDB аппликации, установленные в системе. Если система встречает файл впервые и отсутствуют соответствующие ассоциации, то акция закончится предложением системы, найти соответствующее программное обеспечение в компьютере либо сети интернет.

Иногда случается, что для обслуживания типа файлов .UDB приписана неправильная программа. Это случается в следствии действия враждебных программ, таких как вирусы или вредоносные программы, но чаще всего это результат ошибочного совмещения аппликации с расширением файла .UDB. Если во время обслуживания нового типа файлов .UDB мы укажем системе неправильную программу, то система ошибочно будет рекомендовать ее использование всякий раз, когда будет встречаться файл этого типа. В таком случае следует попробовать повторно выбрать соответствующую аппликацию. Нажмите правой кнопкой мышки на файл .UDB, а затем выберите из меню опцию "Открыть с помощью. " затем "Выбрать программу по умолчанию" . Сейчас выберите одну из установленных аппликаций из вышеуказанного списка и попробуйте снова.

Rate
Rate
Rate
Rate
Rate

Windows
Microsoft Works

Ручное редактирование Реестра Windows

Если наша система не справляется с расширением .UDB и подвели все автоматические и полуавтоматические методы обучения его этому искусству, остается ручное редактирование реестра Windows. Этот реестр хранит всю информацию, касающуюся рабоы нашей операционной системы, в том числе соединения расширений файлов с программами для их обслуживания. Команда REGEDIT вписанная в окне „поиск программ и файлов” или „запустить в случае старших версий операционной системы, предоставляет нам доступ к реестру нашей операционной системы. Все операции, проведенные в реестре (даже не очень сложные, касающееся расширения файла .UDB) имеют значительное влияние на работу нашей системы, поэтому прежде чем проводить какие-либо модификации следует убедится, что сделана копия актуального реестра. Интересующий нас раздел - это ключ HKEY_CLASSES_ROOT. Следующая инструкция показывает, шаг за шагом, как модифицировать реестр, а конкретно запись в реестре, содержащую информацию о файле .UDB.

Справочники «Модели оборудования» и «Модели расходных материалов» входят в стандартную базу и постоянно обновляются: разработчики добавляют новые модели и актуализируют описание существующих, в том числе информацию о совместимости оборудования и расходных материалов. Желательно следить за этими обновлениями, т.к. они могут затрагивать имеющееся на вашем предприятии оборудование.

Стандартная база поставляется с новой версией программы и включена в дистрибутив (файл ps.udb) либо может быть прислана вам персонально. Для загрузки обновлений из стандартной базы в вашу рабочую БД используется процедура импорта.

Программа позволяет импортировать из базы как нужные модели оборудования, так и модели расходных материалов. Для этого в меню «Файл» выберите «Импорт из UDB» и соответствующий пункт. UDB — это формат файла с базой данных. Стандартная база хранится в файле ps.udb, который следует указать в качестве источника для импорта.


Диалоги импорта моделей оборудования и моделей РМ схожи с точки зрения интерфейса. На изображении ниже показан диалог импорта моделей оборудования.


На следующем изображении показан диалог импорта моделей расходных материалов.


Импортировать рекомендуется только те модели, которые используются в организации и у которых имеется новое либо обновленное описание.

Для импорта выполните следующие действия:

1. Используя поле «Фильтр», найдите нужные модели. Фильтр действует на все текстовые поля таблицы. В качестве запроса можно указать наименование, код модели, производителя и т.п. без учета регистра букв. Например, «копир canon fc-100». Для применения фильтра нажмите Enter на клавиатуре или кнопку «Применить». Кнопка «Очистить» позволяет стереть введенный запрос, после чего можно ввести новый.

2. В колонке «Тип» у каждой интересующей модели посмотрите, какие изменения были внесены в ее описание. Возможны следующие варианты:

  • «Такое же описание» — описание не изменилось. Такие модели не требуется импортировать.
  • «Новое описание» — в стандартную базу была добавлена новая модель, которая отсутствует в вашей рабочей базе. При импорте модель будет добавлена в рабочую базу.
  • «Обновление» или «Обновление описания» — обновлено описание модели по сравнению с имеющимся в вашей рабочей базе. При импорте описание модели в рабочей базе будет полностью заменено на обновленное. Однако у моделей оборудования сохранится следующая информация: 1) счетчики, указанные пользователем в свойствах модели на закладке «Основное»; 2) добавленные пользователем расходные материалы, совместимые с данной моделью оборудования, которые указаны на закладке «Слоты и совместимые расходные материалы».
  • «Обновление совместимости» — обновлен список совместимых с моделью оборудования расходных материалов. При импорте в рабочую базу будут добавлены совместимые с моделью оборудования РМ и отражены в ее свойствах на закладке «Слоты и совместимые расходные материалы».

3. Выберите модели для импорта, отметив их галочками. При необходимости используйте кнопки «Выделить все» и «Очистить все».

Обратите внимание на то, что при импорте моделей оборудования вместе с выбранными моделями в рабочую базу импортируется информация обо всех совместимых с ними моделях расходных материалов. По завершении операции импорта в нижней части диалога будет указано количество импортированных моделей оборудования и РМ.


При импорте расходных материалов связанное оборудование не импортируется.

В статье описано устройство резервного копирования и восстановление серверов.

Резервное копирование очень важно. Оно необходимо для сохранение данных на случай поломок и других ошибок. В r_keeper 7 у каждого сервера резервные копии настраивается отдельно.

Для с охранения всех необходимых для восстановления данных р екомендуется настроить резервное копирование для:

  • Сервера справочников
  • Кассового сервера.

Начнем с настроек сервера справочников.

Сервер справочников

Резервные копии сервера справочников по умолчанию хранятся в папке: \base\backups\databases

В папке databases хранятся резервные копии названные датой и временем создания.

  • rk7.udb — главная база данных, в которой хранятся все справочники. Из нее данные попадают в SQL
  • check.udb — база данных с продажами. Данные попадают сюда после закрытия общих смен
  • rk7.bls — содержит картинки планов зала, если такие используются.

Сохранять необходимо все 3 файла.

Обратите внимание, r_keeper 7 не архивирует резервные копии и не может загружать их на FTP-сервер. Для повышения отказоустойчивости мы рекомендуем делать это сторонними средствами.

Для настройки резервного копирования сервера справочников:

  1. Откройте менеджерскую станцию
  2. Перейдите в Настройки > Параметры > Установочные > Сервер справочников > Резервное копирование
  3. Настройте следующие параметры:
    1. Время начала резервного копирования — в разделе Основное в строке Ссылка выберите из выпадающего списка период резервного копирования. Время, в которое системе разрешено выполнять резервное копирование.
      Периоды настраиваются в меню Заказ > Периоды.

    Подробнее о настро йке периодо в читайте в статье справочник периодов

    Нажмите сюда чтобы узнать подробнее о настройке периодов

    Настройка периодов завершена

    Кассовый сервер

    Настройки резервного копирования у каждого кассового сервера свои. Это означает, что если у вас 3 кассовых сервера, у них могут быть 3 разны х настроек резервного копирования.

    Подробнее о структуре хранения данных читайте в статье описание системы и хранения данных

    Если путь резервного копирования не был изменен, по умолчанию эти файлы бэкапа хранятся в папке \midbase\Backup

    В ней содержатся файлы:

    • Work.udb — файл открытой смены
    • sh.udb — файл смены перед закрытием общей смены
    • ns.udb — файл новой смены, после закрытия и до оплаты первого чека, может содержать неоплаченные заказы из прошлой смены.

    Для настройки резервного копирования кассового сервера:

    В разделе Backup вы увидите настройки:

    • Количество копий
    • Путь для бэкапа — относительный или абсолютный
    • Количество смен — количество смен для резервного копирования
    • Периодичность — выполнять резервное копирование каждый указанный промежуток в минутах
    • Количество чеков — по умолчанию 100
    • Выполнять backup — поставьте галочку для активации.

    Восстановление r_keeper 7

    Для восстановления r_keeper 7 из резервной копии:

    1. Установите r_keeper 7 с помощью установщика или через архив
    2. Не запуская серверы, скопируйте из прежней в установленную версию r_keeper 7:
    3. Файлы rk7.udb, check.udb и rk7.bls в папку base сервера справочников
    4. Файл WORK.UDB в папку midbase кассового сервера. Если такой папки нет, то создайте ее. Если в папке \midbase\Backup файл WORK.UDB отсутствует, но есть похожий, например: work2.udb — скопируйте самый последний файл с таким названием и переименуйте в WORK.UDB
    5. Файлы common.ini, repsserv.ini, rk7man.ini, rk7srv.INI, RKEEPER.INI, ShelterConnect.ini, wincash.ini, winprint.ini в:
      1. \bin\win — для r_keeper 7 установленной с помощью архива
      2. соответствующие папки, для r_keeper 7 установленной с помощью установщика.

      В файле rk7srv.INI в разделе [REFSERVER] измените на стройку USESQL=0

      1. Заново настройте связь с новой внешней базой данных и выполните экспорт файлов
      2. В файле rk7srv.INI в разделе [REFSERVER] измените настройку с USESQL=1 на USESQL=0

      Восстановление с помощью резервных копий r_keeper 7 выполнено. Система продолжит работу с сохраненными ранее базами.
      Для того чтобы убедиться в успешном восстановлении системы проверьте:

      Если проверка прошла успешно — система восстановлена, r_keeper 7 продолжит работу с сохраненными ранее базами.

      Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.


      Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.

      Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):


      Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…

      Подготовка к восстановлению

      ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.

      Поскольку в целом база у меня работала, я ограничился обычным дампом базы данных, но исключил таблицу с повреждёнными данными (опция -T, --exclude-table=TABLE в pg_dump).

      Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.

      Проверка файловой системы

      В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.

      Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
      lsof +D /srv

      Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала "/srv". Далее я отмонтировал /srv (umount).

      Проверка файловой системы была выполнена с помощью утилиты e2fsck с ключиком -f (Force checking even if filesystem is marked clean):


      Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2--sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:


      e2fsck говорит, что проблем на уровне файловой системы ext4 не найдено, а это значит, что можно продолжать попытки восстановить базу данных, а точнее вернуться к vacuum full (само собой, необходимо примонтирвоать файловую систему обратно и запустить базу данных).

      Если у вас сервер физический, то обязательно проверьте состояние дисков (через smartctl -a /dev/XXX) либо RAID-контроллера, чтобы убедиться, что проблема не на аппаратном уровне. В моём случае RAID оказался «железный», поэтому я попросил местного админа проверить состояние RAID (сервер был в нескольких сотнях километров от меня). Он сказал, что ошибок нет, а это значит, что мы точно можем начать восстановление.

      Попытка 1: zero_damaged_pages

      Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:

      psql -h 127.0.0.1 -U postgres -s [database_name]

      Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):

      При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.

      Включаем опцию и пробуем делать full vacuum таблицы:




      К сожалению, неудача.

      Мы столкнулись с аналогичной ошибкой:


      pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).

      Попытка 2: reindex

      Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:



      reindex завершился без проблем.

      Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.

      Попытка 3: SELECT, LIMIT, OFFSET

      В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:


      В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:


      К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.

      Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:

      OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
      Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.

      Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.

      Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.

      Попытка 4: снять дамп в текстовом виде

      Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.

      Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:


      В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:

      1. Начинаем снимать дамп в текстовом виде (в виде sql-команд)
      2. В определённый момент времени снятия дампа бы прервалось из-за ошибки, но тектовый файл всё равно сохранился бы на диске
      3. Смотрим конец текстового файла, тем самым мы находим идентификатор (id) последней строки, которая снялась успешно


      Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:


      Далее через tail я просмотрел конец дампа (tail -5 ./my_dump.dump) обнаружил, что дамп прервался на строке с id 186 525. «Значит, проблема в строке с id 186 526, она битая, её и надо удалить!» – подумал я. Но, сделав запрос в базу данных:
      «select * from ws_log_smevlog where обнаружилось, что с этой строкой всё нормально… Строки с индексами 186 530 — 186 540 тоже работали без проблем. Очередная «гениальная идея» провалилась. Позже я понял, почему так произошло: при удалении\изменении данных из таблицы они не удаляются физически, а помечаются как «мёртвые кортежи», далее приходит autovacuum и помечает эти строки удалёнными и разрешает использовать эти строки повторно. Для понимания, если данные в таблице меняются и включён autovacuum, то они не хранятся последовательно.

      Попытка 5: SELECT, FROM, WHERE > Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:


      Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).

      Мне повезло, у меня были созданы индексы по полю id:


      А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.

      К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…

      Попытка 6: SELECT, FROM, WHERE id >= and id <

      У заказчика под БД был выделен отличный сервер: двухпроцессорный Intel Xeon E5-2697 v2, в нашем расположении было целых 48 потоков! Нагрузка на сервере была средняя, мы без особых проблем могли забрать около 20-ти потоков. Оперативной памяти тоже было достаточно: аж 384 гигабайт!

      Поэтому команду нужно было распараллелить:


      Тут можно было написать красивый и элегантный скрипт, но я выбрал наиболее быстрый способ распараллеливания: разбить диапазон 0-1628991 вручную на интервалы по 100 000 записей и запустить отдельно 16 команд вида:


      Но это не всё. По идее, подключение к базе данных тоже отнимает какое-то время и системные ресурсы. Подключать 1 628 991 было не очень разумно, согласитесь. Поэтому давайте при одном подключении извлекать 1000 строк вместо одной. В итоге команда преобразилоась в это:


      Открываем 16 окон в сессии tmux и запускаем команды:

      Через день я получил первые результаты! А именно (значения XXX и ZZZ уже не сохранились):


      Это значит, что у нас три строки содержат ошибку. id первой и второй проблемной записи находились между 829 000 и 830 000, id третьей – между 146 000 и 147 000. Далее нам предстояло просто найти точное значение id проблемных записей. Для этого просматриваем наш диапазон с проблемными записями с шагом 1 и идентифицируем id:

      Счастливый финал

      Мы нашли проблемные строки. Заходим в базу через psql и пробуем их удалить:


      К моему удивлению, записи удалились без каких-либо проблем даже без опции zero_damaged_pages.

      Затем я подключился к базе, сделал VACUUM FULL (думаю делать было необязательно), и, наконец, успешно снял бекап с помощью pg_dump. Дамп снялся без каких либо ошибок! Проблему удалось решить таким вот тупейшим способом. Радости не было предела, после стольких неудач удалось найти решение!

      Благодарности и заключение

      Вот такой получился мой первый опыт восстановления реальной базы данных Postgres. Этот опыт я запомню надолго.

      Ну и напоследок, хотел бы сказать спасибо компании PostgresPro за переведённую документацию на русский язык и за полностью бесплатные online-курсы, которые очень сильно помогли во время анализа проблемы.

      Читайте также: