Таблицы со свойством with oids не поддерживаются 1с
Заказали виртуальный сервер на FastVPS, купили мини сервер 1С и пришло время установки.
В сети нашлась хорошая статья, где все по порядку:
Итак, устанавливаем минимальный CentOS, настраиваем имена хостов, DNSы и сетевые подключения и приступаем собственно к установке серверных компонентов.
1. Установка Postgre SQL server
Для установки использовался рекомендованный (адаптированный) 1С дистрибутив, для чего потребуется скачать его из раздела поддержки пользователей сайта 1С. В моём случае это был "Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) одним архивом (RPM)", который я сохранил в /root/temp. Распаковываем архив:
Устанавливаем в следующей последовательности:
yum install postgresql92-libs-9.2.1-1.1C.x86_64.rpm
yum install postgresql92-9.2.1-1.1C.x86_64.rpm
yum install postgresql92-server-9.2.1-1.1C.x86_64.rpm
yum install postgresql92-contrib-9.2.1-1.1C.x86_64.rpm
Все недостающие зависимости (пакеты) будут установлены в процессе установки этих rpm, хотя на сайте 1С рекомендуют предварительно установить пакеты readline, libtermcap, krb5-libs и openssl, но в моём случае они либо уже были установлены, либо не были обнаружены в репозиториях.
2. Первый запуск Postgre SQL server
В отличии от сценариев установки большинства знакомых мне sql-серверов, postgres требует предварительной инициализации перед запуском, для чего существует два пути - первый, правильный:
Файлы, относящиеся к этой СУБД, будут принадлежать пользователю "postgres".
От его имени также будет запускаться процесс сервера.
Кластер баз данных будет инициализирован с локалью "ru_RU.UTF-8".
Кодировка БД по умолчанию, выбранная в соответствии с настройками: "UTF8".
Выбрана конфигурация текстового поиска по умолчанию "russian".
исправление прав для существующего каталога /var/lib/pgsql/9.2/data. ок
создание подкаталогов. ок
выбирается значение max_connections. 100
выбирается значение shared_buffers. 32MB
создание конфигурационных файлов. ок
создание базы template1 в /var/lib/pgsql/9.2/data/base/1. ок
инициализация pg_authid. ок
инициализация зависимостей. ок
создание системных представлений. ок
загрузка описаний системных объектов. ок
создание правил сортировки. ок
создание преобразований. ок
создание словарей. ок
установка прав для встроенных объектов. ок
создание информационной схемы. ок
загрузка серверного языка PL/pgSQL. ок
очистка базы данных template1. ок
копирование template1 в template0. ок
копирование template1 в postgres. ок
ВНИМАНИЕ: используется проверка подлинности "trust" для локальных подключений.
Другой метод можно выбрать, отредактировав pg_hba.conf или используя ключи -A,
--auth-local или --auth-host при следующем выполнении initdb.
Готово. Теперь вы можете запустить сервер баз данных:
/usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/9.2/data
/usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/9.2/data -l logfile start
Или тот же вывод на английском языке:
could not change directory to "/root"
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "ru_RU.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "russian".
fixing permissions on existing directory /var/lib/pgsql/9.2/data . ok
creating subdirectories . ok
selecting default max_connections . 100
selecting default shared_buffers . 32MB
creating configuration files . ok
creating template1 database in /var/lib/pgsql/9.2/data/base/1 . ok
initializing pg_authid . ok
initializing dependencies . ok
creating system views . ok
creating collations . ok
creating conversions . ok
creating dictionaries . ok
setting privileges on built-in objects . ok
creating information schema . ok
loading PL/pgSQL server-side language . ok
vacuuming database template1 . ok
copying template1 to template0 . ok
copying template1 to postgres . ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
/usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/9.2/data
/usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/9.2/data -l logfile start
Или второй, более простой, но не всегда дающий необходимый результат (зависит от региональных настроек сервера, но у меня иногда приводивший к установке базы данных без поддержки необходимого collation ru_RU.UTF-8):
Инициализируется база данных: [ OK ]
Ошибка установки или изменения национальных настроек информационной базы
Порядок сортировки не поддерживается базой данных
Порядок сортировки не поддерживается базой данных
при установке информационной базы. Теперь можно настраивать автоматический запуск sql-сервера и, собственно, запускать его:
Запускается служба postgresql-9.2: [ OK ]
Всё. Для локальных подключений сервер настроен. В моём случае сервер 1С и сервер SQL находятся на разных машинах, поэтому потребуется настроить и удалённые подключения с авторизацией.
В случае каких-то проблем, читаем содержимое файлов:
Для повышения быстродействия документация PostgreSQL рекомендует как минимум унести журнал /var/lib/pgsql/9.2/data/pg_xlog на отдельный физический том и создать симлинк на него в исходном месте; из личных наблюдений - надо ещё и значительно увеличить размер используемой памяти. но необъятное не охватить, поэтому за статьями по оптимизации работы PostgreSQL для 1С предлагаю обращаться в поисковые системы, а оттуда - на профильные форумы.
3. Настройка пользователей (ролей) Postgre SQL server
Для управления PostgreSQL на начальном этапе потребуется сменить текущего пользователя на postgres и создать нового пользователя из командной строки:
-bash-4.1$ cd /usr/pgsql-9.2/bin
-bash-4.1$ createuser --interactive -P
Введите имя новой роли:server1c
Введите пароль для новой роли:
Должна ли новая роль иметь полномочия суперпользователя? (y - да/n - нет) n
Новая роль должна иметь право создавать базы данных? (y - да/n - нет) y
Новая роль должна иметь право создавать другие роли? (y - да/n - нет) n
В принципе, для обслуживания полезно иметь пользователя с правами суперпользователя - создавать его можно тем же путём.
Теперь осталось разрешить удалённое подключение с авторизацией - для этого в файле /var/lib/pgsql/9.2/data/pg_hba.conf потребуется заменить значение ident на md5 в строке "host all all 0.0.0.0/0 md5" и перезапустить сервис.
Не следует забывать и про настройки iptables - для работы Postgre SQL необходимо открыть как минимум порт tcp 5432, хотя привычнее (да и проще) объявить сетевой интерфейс "внутренним" (разрешить все подключения на интерфейсе).
Для управления сервером потребуется pgAdmin, который можно установить из репозиториев используемого для административных целей линукса, либо скачать с сайта проекта.
4. Установка компонентов сервера 1С
Первый шаг установки сервера 1С мало отличается от аналогичного этапа с SQL-сервером - распаковать скачанный дистрибутив сервера командой tar -vxf rpm64.tar.gz. В итоге получим файлы:
1C_Enterprise83-common-8.3.3-715.x86_64.rpm - основные файлы 1С (включая русский и английский интерфейсы)
1C_Enterprise83-common-nls-8.3.3-715.x86_64.rpm - дополнительные языковые модули
1C_Enterprise83-server-8.3.3-715.x86_64.rpm - сервер 1С
1C_Enterprise83-server-nls-8.3.3-715.x86_64.rpm - дополнительные языковые модули
1C_Enterprise83-ws-8.3.3-715.x86_64.rpm - компоненты вэб-сервера 1С
1C_Enterprise83-ws-nls-8.3.3-715.x86_64.rpm - дополнительные языковые модули
1C_Enterprise83-crs-8.3.3-715.i386.rpm - хранилище конфигураций (только в 32-битном комплекте)
Устанавливаем нужные пакеты командами:
yum install 1C_Enterprise83-common-8.3.3-715.x86_64.rpm
yum install 1C_Enterprise83-server-8.3.3-715.x86_64.rpm
Настраиваем автоматический запуск демона и стартуем его:
Starting 1C:Enterprise 8.3 server: Error: service failed to start!
Starting 1C:Enterprise 8.3 server: OK
Хочу обратить внимание - если сразу после установки сервис (как в приведённом примере) не стартовал, а при второй попытке старта он запустился, скорее всего не настроен DNS - об этом чуть ниже. Если верить информации с многочисленных форумов, то наш сервер уже готов обслуживать до 12 клиентов. Для работы большего числа пользователей, необходимо установить лицензию сервера - либо в виде USB HASP и драйвера, либо в виде электронной лицензии. Про установку аппаратных ключей я уже писал, а установка программных лицензий достаточно проста: запускаем конфигуратор (с клиентской машины; кластер уже должен быть настроен и должна быть информационная база), вызываем "Сервис" - "Получение лицензии", вводим номер комплекта (с коробки или "Регистрационный номер" с карточки из конверта "Пинкоды программной лицензии") и пин-код (с той самой карточки из конверта), ставим галочку "Установка на сервер", вводим имя сервера в соответствующем поле, нажимаем "Далее", говорим, что это - "Первый запуск", заполняем форму "Владелец лицензии" (к стати, я не понял что писать в полях "Фамилия", "Имя", "Отчество" - то ли ответственного за эксплуатацию, то ли генерального директора - оставил поля пустыми, и оно получило лицензию, не ругнувшись), "Далее", "Автоматически" - профит! в /var/1C/licenses на сервере появился файлик XXXXXXXXXXXXXX.lic и серверу "стало хорошо" (если это была многопользовательская лицензия, то клиентам тоже "станет хорошо", т.к. они будут получать лицензии на сервере).
Для работы с графическими объектами и экспорта в xls, могут потребоваться дополнительные пакеты: ImageMagick, freetype (входит в зависимости ImageMagick), libgsf (входит в зависимости ImageMagick), corefonts (отсутствует в репозитариях CentOS - см. раздел 6); для "ТАКСИ" и "Управляемого приложения" они необходимы, для классического толстого клиента вроде бы не особо нужны, но 1С всё равно ругается на их отсутствие, хоть и работает.
По умолчанию сервер 1С слушает порт tcp 1541(1540) и для соединений использует диапазон портов 1560-1691.
5. Настройка экземпляра (кластера) сервера 1С
Информации о наличии оснастки управления сервером 1С для Linux мне не попадалось, так что для управления сервером будем использовать традиционную оснастку mmc для Windows "Администрирование серверов 1С:Предприятия", которую следует поставить из дистрибутива технологической платформы для Windows.
В результате детального изучения проблемы с применением strace удалось выяснить, что агент сервера при запуске ищет настройки по пути
/.1cv8/1C/1cv8/ (в домашнем каталоге запустившего пользователя) и если не находит, пытается создать настройки кластера по умолчанию, для чего ему нужно имя хоста (выяснено экспериментально), и если верить "Руководству администратора", нужен корректно работающий DNS; экспериментально же был установлен факт, что сначала ragent читает файл /etc/hosts, затем обращается к DNS-серверу, а затем вызывает uname и снова лезет в hosts и к DNS и если не находит сопоставления, аварийно завершается. Итак, для нормального запуска потребуется полноценная и правильно настроенная сетевая инфраструктура, ну а в отсутствии работающего DNS достаточно дописать строчку в /etc/hosts и привести его примерно к такому виду:
192.168.122.227 vh-1c83.test.lan vh-1c83
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОШИБКА: нет доступа к языку c
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОШИБКА: ошибка синтаксиса (примерное положение: "application") в символе 24
ОПЕРАТОР: lock table pg_class in application share mode
ПРЕДУПРЕЖДЕНИЕ: нет незавершённой транзакции
ОШИБКА: тип "mvarchar" не существует в символе 31
ОПЕРАТОР: create table Config (FileName mvarchar(128) not null, Creation timestamp not null, Modified timestamp not null, Attributes int not null, DataSize int8 not null, BinaryData bytea not null, PartNo int not null, PRIMARY KEY (FileName, PartNo))
ОШИБКА: нет прав для изменения параметра "lc_messages"
ОШИБКА: нет доступа к языку c
Что порадовало - теперь в 1С можно работать непосредственно из Linux, что актуально для компаний, использующих его как основную ОС в корпоративной сети (я сейчас работаю как раз в такой компании); из неожиданностей - что при установке клиента 1С, он заявляет о зависимости от сервера и требует его установки, но потом ставится, прописывает значки запуска в "Офис" - "Финансы" и работает довольно сносно (по ощущениям - чуть менее комфортно, чем 8.2 под Windows, но заметно приятнее, чем тот же 8.2 через WINE от Ethersoft).
6. Установка недостающих зависимостей
Кроме "ImageMagick" и шрифтов, для возможности сохранения в табличные файлы (кроме xls - его я пока не заставил формироваться, хотя xlsx формируется), на клиенте должны быть установлены пакеты "libMagickWand5", "libgomp1", "liblcms2-2" и "libbz2-1" - на ряде машин они отсутствовали. При чём той же разрядности, что и сервер 1С (см. п. 4).
7. Настройка аппаратного hasp для виртуализированного сервера 1С (работающего на виртуальной машине KVM)
Не планировал описывать эту процедуру, но раз уж столкнулся с такой ситуацией, опишу. Итак, на этот раз я использовал драйвер от "Alladin Knowledge Systems USB HASP", предоставляемый компанией Sentinel - мне попались две версии:
Можно воспользоваться драйвером эзерсофт - окончательный выбор следует делать из опыта практической эксплуатации.
Этот параметр определяет, будет ли при разборе вводимого массива распознаваться строка NULL без кавычек как элемент массива, равный NULL. Значение по умолчанию, on , позволяет задавать NULL в качестве элементов вводимого массива. Однако до версии 8.2 PostgreSQL не поддерживал ввод элементов NULL в массивах, а воспринимал NULL как обычный элемент массива со строковым значением « NULL » . Для обратной совместимости с приложениями, зависящими от старого поведения, эту переменную можно отключить (присвоив ей off ).
Заметьте, что массивы, содержащие NULL, можно создать, даже когда эта переменная имеет значение off . backslash_quote ( enum )
Этот параметр определяет, можно ли будет представить знак апострофа в строковой константе в виде \' . В стандарте SQL определён другой, предпочитаемый вариант передачи апострофа, дублированием ( '' ), но Postgres Pro исторически также принимал вариант \' . Однако применение варианта \' сопряжено с угрозами безопасности, так как в некоторых клиентских кодировках существуют многобайтные символы, последний байт которых численно равен ASCII-коду \ . Если код на стороне клиента выполнит экранирование некорректно, это может открыть возможности для SQL-инъекции. Предотвратить этот риск можно, запретив серверу принимать запросы, в которых апостроф экранируется обратной косой. Допустимые значения параметра backslash_quote : on (принимать \' всегда), off (не принимать никогда) и safe_encoding (принимать, только если клиентская кодировка не допускает присутствия ASCII-кода \ в многобайтных символах). Значение по умолчанию — safe_encoding .
Заметьте, что в строковой константе, записанной согласно стандарту, знаки \ обозначают просто \ . Этот параметр влияет только на восприятие строк, не соответствующих стандарту, в том числе с синтаксисом спецпоследовательностей ( E'. ' ). default_with_oids ( boolean )
Этот параметр определяет, будут ли команды CREATE TABLE и CREATE TABLE AS без явных указаний WITH OIDS и WITHOUT OIDS добавлять столбец OID в создаваемые таблицы. Он также устанавливает, будут ли столбцы OID добавляться в таблицы, создаваемые командой SELECT INTO . По умолчанию значение этого параметра — off (столбцы OID не добавляются); в PostgreSQL версии 8.0 и ранее он был включён ( on ).
Практика использования OID в пользовательских таблицах считается устаревшей, так что в большинстве инсталляций не следует включать этот параметр. Приложения, которым требуется столбец OID в определённой таблице, могут явно указать WITH OIDS при создании таблицы. Этот параметр следует включать только для совместимости со старыми приложениями, которые не делают этого. escape_string_warning ( boolean )
Когда этот параметр включён, сервер выдаёт предупреждение, если обратная косая черта ( \ ) встречается в обычной строковой константе (с синтаксисом '. ' ) и параметр standard_conforming_strings отключён. Значение по умолчанию — on (вкл.).
Приложения, которые предпочитают использовать обратную косую в виде спецсимвола, должны перейти к применению синтаксиса спецстрок ( E'. ' ), так как по умолчанию теперь в обычных строках обратная косая воспринимается как обычный символ, в соответствии со стандартом SQL. Включение данного параметра помогает найти код, нуждающийся в модификации. lo_compat_privileges ( boolean )
В PostgreSQL до версии 9.0 для больших объектов не назначались права доступа, и поэтому они были всегда доступны на чтение и запись для всех пользователей. Если установить для этого параметра значение on , существующие теперь проверки прав отключаются для совместимости с предыдущими версиями. Значение по умолчанию — off . Изменить этот параметр могут только суперпользователи.
Установка данного параметра не приводит к отключению всех проверок безопасности, связанных с большими объектами — затрагиваются только те проверки, которые изменились в PostgreSQL 9.0. Например, функции lo_import() и lo_export() будут требовать прав суперпользователя вне зависимости от данного значения. operator_precedence_warning ( boolean )
Когда этот параметр включён, анализатор запроса будет выдавать предупреждение для всех конструкций, которые поменяли поведение после PostgreSQL 9.4 в результате изменения приоритетов операторов. Это полезно для аудита, так как позволяет понять, не сломалось ли что-то вследствие этого изменения. Но в производственной среде включать его не следует, так как предупреждения могут выдаваться и тогда, когда код абсолютно правильный и соответствует стандарту SQL. Значение по умолчанию — off .
За подробностями обратитесь к Подразделу 4.1.6. quote_all_identifiers ( boolean )
Принудительно заключать в кавычки все идентификаторы, даже если это не ключевые слова (сегодня), при получении SQL из базы данных. Это касается вывода EXPLAIN , а также результатов функций типа pg_get_viewdef . См. также описание аргумента --quote-all-identifiers команд pg_dump и pg_dumpall . sql_inheritance ( boolean )
Этот параметр определяет, будет ли использование таблиц без уточнений подразумевать включение дочерних таблиц в иерархии наследования. Значение по умолчанию — on , что означает, что дочерние таблицы включаются (то есть по умолчанию подразумевается суффикс * ). При значении off дочерние таблицы не включаются (то есть подразумевается префикс ONLY ). Стандарт SQL требует, чтобы дочерние таблицы включались, так что вариант off не соответствует стандарту, но предлагается для совместимости с PostgreSQL до версии 7.1. За дополнительными сведениями обратитесь к Разделу 5.9.
Поведение с выключенным sql_inheritance считается устаревшим, так как оно не только противоречит стандарту SQL, но и провоцирует ошибки. При обсуждении наследования в этом руководстве обычно предполагается, что данный параметр имеет значение on . standard_conforming_strings ( boolean )
Этот параметр определяет, будет ли обратная косая черта в обычных строковых константах ( '. ' ) восприниматься буквально, как того требует стандарт SQL. Начиная с версии PostgreSQL 9.1, он имеет значение on (в предыдущих версиях значение по умолчанию было off ). Приложения могут выяснить, как обрабатываются строковые константы, проверив этот параметр. Наличие этого параметра может также быть признаком того, что поддерживается синтаксис спецпоследовательностей ( E'. ' ). Этот синтаксис (Подраздел 4.1.2.2) следует использовать, если приложению нужно, чтобы обратная косая воспринималась как спецсимвол. synchronize_seqscans ( boolean )
Этот параметр включает синхронизацию обращений при последовательном сканировании больших таблиц, чтобы эти операции читали один блок примерно в одно и то же время, и, таким образом, нагрузка разделялась между ними. Когда он включён, сканирование может начаться в середине таблицы, чтобы синхронизироваться со сканированием, которое уже выполняется. По достижении конца таблицы сканирование « заворачивается » к началу и завершает обработку пропущенных строк. Это может привести к непредсказуемому изменению порядка строк, возвращаемых запросами, в которых отсутствует предложение ORDER BY . Когда этот параметр выключен (имеет значение off ), реализуется поведение, принятое до версии 8.3, когда последовательное сканирование всегда начиналось с начала таблицы. Значение по умолчанию — on .
18.13.2. Совместимость с разными платформами и клиентами
Когда этот параметр включён, проверки вида выражение = NULL (или NULL = выражение ) воспринимаются как выражение IS NULL , то есть они истинны, если выражение даёт значение NULL, и ложны в противном случае. Согласно спецификации SQL, сравнение выражение = NULL должно всегда возвращать NULL (неизвестное значение). Поэтому по умолчанию этот параметр выключен (равен off ).
Однако формы фильтров в Microsoft Access генерируют запросы, в которых проверка на значение NULL записывается как выражение = NULL , так что если вы используете этот интерфейс для обращения к базе данных, имеет смысл включить данный параметр. Так как проверки вида выражение = NULL всегда возвращают значение NULL (следуя правилам стандарта SQL), они не очень полезны и не должны встречаться в обычных приложениях, так что на практике от включения этого параметра не будет большого вреда. Однако начинающие пользователи часто путаются в семантике выражений со значениями NULL, поэтому по умолчанию этот параметр выключен.
Заметьте, что этот параметр влияет только на точную форму сравнения = NULL , но не на другие операторы сравнения или выражения, результат которых может быть равнозначен сравнению с применением оператора равенства (например, конструкцию IN ). Поэтому данный параметр не может быть универсальной защитой от плохих приёмов программирования.
Данные, которые определяют логику функционирования системы на базе 1С:Предприятия, относятся к информационной базе. Хранение информационной базы осуществляется в базе данных с виде набора таблиц, для чего 1С:Предприятие 8.1 может использовать одну из четырех систем управления базами данных (СУБД):
* Встроенную в 1С:Предприятие 8.1 (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1Cv8.1CD. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в 1С:Предприятие 8.1 СУБД.
* Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.
* PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.
* IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.
На уровне объектов базы данных (таблиц, полей, индексов и т. п.) как файловый так и клиент-серверный вариант информационной базы имеют сходный формат (отличающийся несущественными деталями). Некоторая информация об этом формате содержится ниже.
Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:
* Config - основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия.
* ConfigSave - конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении "Обновления конфигурации базы данных" в Конфигураторе, а наоборот - при выполнении в Конфигураторе операции "Конфигурация - Конфигурация базы данных - Вернуться к конфигурации БД".
* Files содержит служебную информацию, например, о работе с хранилищем конфигурации.
* Params содержит параметры информационной базы. Среди них:
=> Список пользователей информационной базы.
=> Национальные настройки информационной базы.
=> Таблица соответствия объектов метаданных и объектов базы данных (таблиц, полей, индексов).
=> Некоторая другая информация.
* _YearOffset - смещение дат в базе данных. Эта таблица создается только при использовании Microsoft SQL Server.
* DBSchema содержит информацию о структуре базы данных 1С:Предприятия и определяет другие объекты базы данных, используемые данной информационной базой.
Перечень и структура других таблиц базы данных определяется конкретной конфигурацией, а именно, определенными в ней объектами метаданных. Имя каждой таблицы состоит из буквенного префикса и следующего за ним номера. Префикс определяет назначение таблицы, а номер позволяет различать таблицы одинакового назначения, относящиеся к разным объектам метаданных. Если в качестве СУБД используется IBM DB2, то описанную структуру имеют не имена таблиц, а их псевдонимы.
Если в конфигурации определен хотя бы один план обмена с установленным флагом "Распределенная информационная база", то будут созданы следующие таблицы:
* _ConfigChangeRec - таблица регистрации изменений объектов конфигурации.
* _ConfigChangeRec_ExtProps - таблица имен файлов измененных внешних свойств объектов конфигурации.
Ниже перечислены различные объекты метаданных, которым могут соответствовать те или иные таблицы.
* Константы
=> _Consts содержит текущие значения всех констант, определенных в конфигурации.
=> _ConstsChangeRec - таблица регистрации изменений констант. Создается, если хотя бы одна константа участвует хотя бы в одном плане обмена.
* Планы обмена
=> _Node<n> - таблица плана обмена.
=> _Node<n>_VT<k> - табличная часть плана обмена, создается для каждой табличной части.
* Справочники
=> _Reference<n> - таблица справочника.
=> _Reference<n>_VT<k> - табличная часть справочника - для каждой табличной части.
=> _ReferenceChangeRec<n> - таблица регистрации изменений справочника. Создается, если справочник участвует хотя бы в одном плане обмена.
* Документы
=> _Document<n> - таблица документов для каждого объекта метаданных "документ".
=> _Document<n>_VT<k> - табличная часть документа - для каждой табличной части каждого документа.
=> _DocumentChangeRec<n> - таблица регистрации изменений объекта метаданных типа "документ". Создается для каждого объекта метаданных типа "документ", если он участвует хотя бы в одном плане обмена.
* Последовательности документов
=> _Sequence<n> - таблица регистрации документов - для каждой последовательности.
=> _SequenceBoundary<n> - таблица границ последовательности - для каждой последовательности.
=> _SequenceChangeRec<n> - таблица регистрации изменений последовательности. Создается для каждой последовательности, которая участвует хотя бы в одном плане обмена.
* Журналы документов.
=> _DocumentJournal<n> - таблица журнала документов, создается для каждого журнала документов.
* Перечисления
=> _Enum<n> - таблица перечисления - по одной для каждого перечисления.
* Планы видов характеристик
=> _Chrc<n> - основная таблица плана видов характеристик.
=> _Chrc<n>_VT<k> - табличная часть плана видов характеристик - для каждой табличной части.
=> _ChrcChangeRec<n> - таблица регистрации изменений плана видов характеристик. Создается, если план видов характеристик участвует хотя бы в одном плане обмена.
* Планы счетов
=> _Acc<n> - основная таблица плана счетов.
=> _Acc<n>_ExtDim<k> - таблица видов субконто плана счетов, создается для плана счетов в том случае, если максимальное количество субконто больше нуля.
=> _Acc<n>_VT<k> - табличная часть плана счетов, создается для каждой табличной части плана счетов.
=> _AccChangeRec<n> - таблица регистрации изменений плана счетов. Создается, если план счетов участвует хотя бы в одном плане обмена.
* Планы видов расчета
=> _CalcKind<n> - основная таблица плана видов расчета.
=> _CalcKind<n>_BaseCK - таблица базовых видов расчета, создается для плана видов расчета в случае, если его свойство "Зависимость от базы" имеет значение, отличное от "Не зависит".
=> _CalcKind<n>_DisplacedCK - таблица вытесняемых видов расчета, создается для плана видов расчета в случае, если у него установлен флаг "Использует период действия".
=> _CalcKind<n>_LeadingCK - таблица ведущих видов расчета - для каждого плана видов расчета.
=> _CalcKindDN<n> - вспомогательная таблица для порядка вытеснения, создается, если у плана видов расчета установлен флаг "Использует период действия".
=> _CalcKind<n>_VT<k> - табличная часть плана видов расчета, создается для каждой табличной части.
=> _CalcKindChangeRec<n> - таблица регистрации изменений плана видов расчета. Создается, если план видов расчета участвует хотя бы в одном плане обмена.
* Регистры сведений
=> _InfoReg<n> - таблица движений регистра сведений.
=> _InfoRegChangeRec<n> - таблица регистрации изменений регистра сведений. Создается, если регистр сведений участвует хотя бы в одном плане обмена.
* Регистры накопления
=> _AccumReg<n> - таблица движений регистра накопления.
=> _AccumRegTotals<n> - таблица итогов регистра накопления, если регистр поддерживает остатки.
=> _AccumRegTurnovers<n> - таблица оборотов регистра накопления, если регистр поддерживает обороты.
=> _AccumRegChangeRec<n> - таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
=> _AccumRegOptions - таблица настроек хранения итогов регистров накопления одна на все регистры накопления.
* Регистры бухгалтерии
=> _AccntReg<n> - таблица движений регистра бухгалтерии.
=> _AccntRegED<n> - таблица значений субконто регистра бухгалтерии, создается в том случае, если он ссылается на план счетов, у которого максимальное количество субконто больше нуля.
=> _AccTtl0<n> - таблица итогов по счету.
=> _AccTtl<i><n> - где i от 1 до максимального количества субконто. Таблица итогов по счету с количеством видов субконто равным i.
=> _AccTtlC<n> - таблица итогов оборотов между счетами, только для регистра бухгалтерии поддерживающего корреспонденцию.
=> _AccntRegChangeRec<n> - таблица регистрации изменений регистра бухгалтерии. Создается, если регистр бухгалтерии участвует хотя бы в одном плане обмена.
=> _AccntRegOptions - таблица настроек хранения итогов одна на все регистры бухгалтерии.
* Регистры расчета
=> _CalcReg<n> - таблица движений регистра расчета.
=> _CalcRegActPer<n> - таблица фактических периодов действия для регистра расчета, создается, если у регистра расчета установлен флаг "Период действия".
=> _CalcRegChangeRec<n> - таблица регистрации изменений регистра расчета. Создается для каждого регистра расчета, участвующего хотя бы в одном плане обмена.
=> _CalcRegRecalc<n> - таблица перерасчета регистра расчета, создается для каждого перерасчета.
=> _CalcRegRecalcChangeRec<n> - таблица регистрации изменений перерасчета. Создается, если перерасчет участвует хотя бы в одном плане обмена.
* Бизнес-процессы
=> _BPRoutePoint<n> - таблица точек маршрута бизнес-процесса для каждого бизнес-процесса.
=> _BusinessProcess<n> - основная таблица бизнес-процесса.
=> _BusinessProcess<n>_VT<k> - табличная часть бизнес-процесса для каждой табличной части.
=> _BusinessProcessChangeRec<n> - таблица регистрации изменений бизнес-процесса. Создается для каждого бизнес-процесса, участвующего хотя бы в одном плане обмена.
* Задачи
=> _Task<n> - основная таблица задачи.
=> _Task<n>_VT<k> - табличная часть задачи для каждой табличной части.
=> _TaskChangeRec<n> - таблица регистрации изменений в задачах. Создается для каждого объекта метаданных типа "задача", который участвует хотя бы в одном плане обмена.
При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.
Количество этих таблиц зависит от функциональности конфигурации и может быть достаточно большим. В штатном режиме 1С:Предприятие не выполняет проверку их наличия, а также целостности и непротиворечивости содержащихся в них данных. Поэтому важно, чтобы база данных, в которой размещена информационная база 1С:Предприятия 8.1, была защищена от несанкционированного доступа и ее модификация выполнялась только средствами 1С:Предприятия. Для проверки необходимо использовать функцию "Администрирование - Тестирование и исправление", встроенную в конфигуратор.
Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1Cv8.1CD.
В конфигураторе есть специальная функция: Администрирование - Выгрузить информационную базу. С ее помощью можно выгрузить в указанный файл (файл выгрузки) все данные, относящиеся к информационной базе, и больше никакие. Обратная ей функция "Загрузить информационную базу" позволяет в текущую информационную базу вместо существующих загрузить все данные из файла выгрузки. Эти функции также можно использовать для резервного копирования данных информационной базы как в файловом так и в клиент-серверном варианте.
Как просмотреть структуру таблиц информационной базы?
Достаточно часто у разработчика возникает потребность формировать для записей таблицы PostgreSQL некие уникальные идентификаторы — как при вставке записей, так и при их чтении.
Таблица счетчиков
Казалось бы — чего проще? Заводим отдельную табличку, в ней — запись со счетчиком. Надо получить новый идентификатор — читаем оттуда, чтобы записать новое значение — делаем UPDATE …
Так делать не надо! Потому что завтра же вам придется решать проблемы:
- постоянных пересекающихся блокировок при UPDATE
см. PostgreSQL Antipatterns: сражаемся с ордами «мертвецов» - постепенной деградации скорости доступа к данным таблицы счетчиков
см. PostgreSQL Antipatterns: обновляем большую таблицу под нагрузкой - … и необходимости ее зачистки при активных транзакциях, которые будут вам мешать
см. DBA: когда пасует VACUUM — чистим таблицу вручную
Объект SEQUENCE
Для таких задач в PostgreSQL предусмотрена отдельная сущность — SEQUENCE . Она нетранзакционна, то есть не вызывает блокировок, но две «параллельные» транзакции заведомо получат разные значения.
Чтобы получить следующий ID из последовательности, достаточно воспользоваться функцией nextval :
Иногда необходимо получить сразу несколько ID — для потоковой записи через COPY, например. Использовать для этого setval(currval() + N) — в корне неправильно! По той простой причине, что между вызовами «внутренней» ( currval ) и «внешней» ( setval ) функций конкурирующая транзакция могла изменить текущее значение последовательности. Корректный способ — вызвать nextval нужное количество раз:
Псевдотип serial
В «ручном» режиме с последовательностями работать не очень удобно. Но ведь типовая задача у нас — обеспечить вставку новой записи с новым sequence-ID! Специально для этой цели в PostgreSQL придуман псевдотип serial , который при генерации таблицы «разворачивается» во что-то типа id integer NOT NULL DEFAULT nextval('tbl_id_seq') .
Запоминать имя автоматически сгенерированной и привязанной к полю последовательности — не надо, для этого есть функция pg_get_serial_sequence(table_name, column_name) . Эту же функцию можно использовать в собственных DEFAULT -подстановках — например, если есть необходимость сделать общую последовательность на несколько таблиц сразу.
Однако, поскольку работа с последовательностью нетранзакционна, если идентификатор из нее получала rollback'нувшаяся транзакция, то в сохраненных записях таблицы последовательность ID окажется «дырявой».
GENERATED-столбцы
Начиная с PostgreSQL 10, появилась возможность объявления идентифицирующего столбца ( GENERATED AS IDENTITY ), соответствующего стандарту SQL:2003. В варианте GENERATED BY DEFAULT поведение эквивалентно serial , а вот с GENERATED ALWAYS все интереснее:
Да, чтобы вставить конкретное значение «поперек» такого столбца, придется приложить дополнительные усилия с помощью OVERRIDING SYSTEM VALUE :
Заметьте, что теперь у нас в таблице два одинаковых значения id = 1 — то есть GENERATED не накладывает дополнительных UNIQUE-условий и индексов, а является исключительно декларацией, равно как и serial .
В общем случае, на современных версиях PostgreSQL использование serial не рекомендуется с предпочтительной заменой его на GENERATED . Кроме, разве что, ситуации поддержки кросс-версионных приложений, работающих с PG ниже 10.
Генерируемый UUID
Все хорошо, пока вы работаете в рамках одного экземпляра БД. Но когда их несколько, адекватного способа синхронизации последовательностей не существует (впрочем, это не мешает «неадекватно» их синхронизировать, если очень хочется). Тут на помощь приходит тип UUID и функции генерации значений для него. Я обычно использую uuid_generate_v4() как наиболее «случайную».
Скрытые системные поля
tableoid/ctid
Иногда при выборке записей из таблицы требуется как-то адресоваться к конкретной «физической» записи, или узнать, из какой конкретной секции была получена та или иная запись при обращении к «родительской» таблице при использовании наследования.
В этом случае нам помогут скрытые системные поля, присутствующие в каждой записи:
- tableoid хранит oid -идентификатор таблицы — то есть tableoid::regclass::text дает имя конкретной таблицы-секции
- ctid — «физический» адрес записи в формате (<страница>,<смещение>)
Вплоть до PostgreSQL 11 существовала возможность объявить при создании таблицы атрибут WITH OIDS :
Каждая запись этой таблицы получала дополнительное скрытое поле oid с глобально-уникальным значением в рамках БД — как это организовано для системных таблиц вроде pg_class , pg_namespace ,…
При вставке записи в такую таблицу генерируемое значение возвращается сразу с результатом запроса:
Такое поле невидимо при «обычном» запросе таблицы:
Его, как и остальные системные поля надо запрашивать в явном виде:
Правда, значение oid имеет всего 32 бита, поэтому весьма несложно получить переполнение, после которого даже создать никакую таблицу (ей нужен новый oid !) не удастся. Поэтому, начиная с PostgreSQL 12, WITH OIDS более не поддерживается.
«Честное» время clock_timestamp
Иногда при длительном выполнении запроса или процедуры хочется привязать к записи «текущее» время. Неудача ждет того, кто попытается для этого использовать функцию now() — она возвратит одно и то же значение в рамках всей транзакции.
Чтобы получить «вот прямо текущее» время, существует функция clock_timestamp() (и еще пучок ее собратьев). Чем отличается поведение этих функций можно увидеть на примере простого запроса:
Читайте также: