22.03.12 — 06:39
Добрый день.
Случилась беда с базой
Конф: v8 УТ 10.3.6.8
база на PostgreSQL 8.4.3-3.1C
При тестировании и исправлении вылетает ошибка
Ошибка СУБД
Error: Could not read block 26637 of relation base/50468/3305609: invalid argument
В конфигураторе останавливается на надписи:
Проверка логической целостности. Регистры накопления. Продажи. — 15%
Дамп базы не делается ни средствами 1с ни PostgreSQL.
База работает. Сбоев нет.
Кто сталкивался? Что делать?
1 — 22.03.12 — 06:44
прогони копию базы, её же штатной проверкой, в папке 1cv82/../bin/chdbfl.exe
как вариант попробуй
2 — 22.03.12 — 06:50
Не уследил в какой момент перестали создаваться копии. И уже все затерлись ((..Есть совсем старые но там нет ошибок.
3 — 22.03.12 — 07:09
(2) а новую копию создать нельзя??
4 — 22.03.12 — 07:15
В том то и дело, не могу сделать резервную копию вылетает с ошибкой. Думаю связано как раз что то с этим блоком.
5 — 22.03.12 — 07:16
Ну пробуй через XML в чистую базу выгрузить, возможно частями
6 — 22.03.12 — 07:21
Хотелось бы конечно выгрузить базу штатными средствами и потом уже сменить PostgreSQL или дело не в нем ведь?
7 — 22.03.12 — 07:34
(6) я просто не знаю, в SQL вообще не скопировать базу как в файловых??? там ведь есть путь к базе?
8 — 22.03.12 — 07:34
Поди БД файловая
9 — 22.03.12 — 07:36
можно вообще очистить этот регистр в субд, только потом востанавливать тяжело будет.
судя по ошибке у тебя сама посгрей посыпалась
10 — 22.03.12 — 07:37
Я ведь написал БД на PostgreSQL, Резервная копия не делается ни средствами 1с ни средствами Postgre
11 — 22.03.12 — 07:37
(8) Написано же, «база на PostgreSQL 8.4.3-3.1C «
12 — 22.03.12 — 07:40
(9) Отчеты строятся по любым периодам, ошибок не бывает..или это не связано?
13 — 22.03.12 — 07:40
А по теме, «Продажи» — регистр оборотный, перепроведением восстановится. Так что грохнуть таблицу регистра, загрузить конфигурацию, реструктуризацию запустить, потом перепровести.
14 — 22.03.12 — 07:43
(13) Опасно конечно заниматься этим без резервной копии..может есть ещё варианты?
15 — 22.03.12 — 07:48
(14) а копию сделать кто мешает?
останавливаешь службу и копируешь файлы
16 — 22.03.12 — 07:50
(14) Образ винчестера сделай.
17 — 22.03.12 — 07:50
(14)А постгри потом стартанет если заменить базу на старую?
18 — 22.03.12 — 07:51
(16)
19 — 22.03.12 — 07:56
(17) Без танцев с бубном точно нет, но зато файлы останутся…
«Продажи» — первый поломатый регистр, на котором спотыкается ТиИ. Их может быть 100500…
20 — 22.03.12 — 08:01
(19) Плохо дело чувствую
21 — 22.03.12 — 08:05
Кстати, идея. Недавно делал РБД с этого узла и она создалась без сбоев. Там конечно обрезанный узел но нужно попробовать на полном плане. А с файловой уже проще.
22 — 22.03.12 — 08:16
сделай так:
1. создай новую пустую базу с этой конфигурацией
2. экспортом гони таблицы из поломатой в новую
3. составляешь список таблиц которые не удалось копирнуть
4. принимаешь решение чего дальше
способ безопасный, геморный, но понятный
23 — 22.03.12 — 08:20
(22) +1 за такой подход
24 — 22.03.12 — 08:27
(22) Спасибо попробую.
Один вопрос Экспорт — это ты имеешь ввиду средство 1с или Postgre? Ни разу не сталкивался.
25 — 22.03.12 — 08:31
(24) средстави СУБД, я с пости не работал, я только со скулем, зато так например востанавливал базу 7.7 примерно 60 гигов после краха винта и скульного рековера, там черти что было
26 — 22.03.12 — 08:39
(25) Понял Спасибо. Буду пробовать. Отпишусь.
27 — 22.03.12 — 08:42
Беда случилась уже давно когда Выбирали СУБД на учёбу забыли денег выделить ..)
28 — 22.03.12 — 08:55
))
29 — 23.03.12 — 07:26
Нашел таблицу которая дает ошибку.
accumreg7721
ERROR: could not read block 26637 of relation base/50468/3305609: Invalid argument
Кто знает что за таблица?
30 — 23.03.12 — 08:03
(29) регист…
теперь тупо в новой базе сделай ТиИс и потом полное перепроведение, и все будет рабочее.
31 — 23.03.12 — 08:03
(29) ERROR: could not read block 26637 of relation base/50468/3305609: Invalid argument
судя по последним словам, может это по больничным листам?)))))))
32 — 23.03.12 — 08:08
(30) хотя лучше не перепроведение, а что-то более правильное, на сколько я понял у тебя один регист «продажы» крякнул, подумай как его заполнить без перепроведения
33 — 23.03.12 — 08:10
(29) Объясни что такое ТиИс?
И как в новой? — я не могу её залить в новую базу.
(30) Да конечно лучше как то заполнить )
34 — 23.03.12 — 08:14
(33) Тестирование и Исправление.
35 — 23.03.12 — 08:17
Тоесть перенести все таблицы в новую базу кроме этой и уже например средствами 1с её заполнить..? дошло
36 — 23.03.12 — 08:27
А можно как то посмотреть что это за блок такой 26637?
37 — 23.03.12 — 08:28
(36) никак, это к 1с не имеет отношение, это номер страницы в файле субд
38 — 23.03.12 — 08:30
а вообще если такая ошибка появилась — это ОЧЕНЬ серьезный звонок админу, вариантов масса, от начала рассыпания дисков, до серьезных проблемм с софтом.
нет никакой гарантии что на этом сервере сабж не повторится но уже в КРУПНЫХ МАСШТАБАХ
39 — 23.03.12 — 10:23
Спасибо за помощь vde69
40 — 23.03.12 — 10:58
В Postgre подобные ошибки случаются с завидным постоянством, и, что самое плохое, — нет штатных утилит по лечению тип DBCC в MSSQL, поэтому главное правило — регулярные архивы.
Схема лечения такой ошибки следующая.
В pgadmin нужно запустить переиндексацию с перебором всех таблиц, например, подобным скриптом:
CREATE OR REPLACE FUNCTION _Reindex_Base(
schema_name in name,
result out bigint
)
LANGUAGE plpgsql as $BODY$
DECLARE table_name name;
BEGIN
FOR table_name IN (
SELECT t.table_name
FROM information_schema.tables t
WHERE t.table_schema = schema_name
AND t.table_type = ‘BASE TABLE’
— AND t.table_name > ‘_reference84’
ORDER BY t.table_name
) LOOP
raise info ‘reindex %s’, table_name;
EXECUTE ‘REINDEX TABLE ‘
||quote_ident(schema_name)||’.’||quote_ident(table_name);
END LOOP;
RETURN;
END;
$BODY$;
SELECT result
FROM _Reindex_Base(‘public’);
Нормальные таблицы будут переиндексироваться, на битых будет спотыкаться.
Битые таблицы потом нужно идентифицировать, каким объектам базы они соответствуют — благо обработок по представлению структуре базы везде валяется немеряно.
Далее битые таблицы придется удалить и пересоздать — проще всего автогенерируемым CREATE скриптом в том же pgadmin.
После этого восстанавливать данные, исходя из важности потерянных таблиц и имеющихся архивов. Служебные данные, типа итогов регистров — переформировать; движения регистров — можно восстанавливать, можно заново получить перепроведением. Справочники, документы, перечисления, независимые регистры сведений — только восстанавливать из бэкапов — либо тянуть в виде таблиц Postgre, либо разворачиать архивные базы полностью и выгружать-загружать средствами 1С.
41 — 23.03.12 — 11:01
(40) вот по этому я и сижу на скуле а пости извени это пРости какое-то
42 — 23.03.12 — 11:48
(40) Спасибо большое, сейчас пробую.
43 — 23.03.12 — 11:52
не гонялся бы ты поп за дешевизной…
44 — 23.03.12 — 12:49
Да уже тоже сижу думаю об этом..)
45 — 23.03.12 — 13:39
Бесплатность линуксов нивелируется стоимостью поддержки.
46 — 23.03.12 — 14:03
Это всего лишь стоимость несделанного вовремя бэкапа(ОС, СУБД и все остальное, практически, не имеет значения). Ключевая фраза в (3) — «Не уследил…»
ansh15
47 — 23.03.12 — 14:05
Извините, в (2)
Ошибка СУБД:
Продолжение сообщения может быть различным:
-
1. DATABASE не пригоден для использования
2. ERROR: type «tt7» already exists
3. ERROR: could not read block
DATABASE не пригоден для использования
Пример полного текста ошибки:
Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: DATABASE не пригоден для использования |
Описание ошибки:
База не запускается после установки и создания.
Решения:
Установим версию предназначенную для работы с 1С:Предприятием. Скачать такую можно с сайта 1С (при наличии купленного ИТС и открытого доступа), или приобрести у PostgresPro.
Либо проверим все ли зависимости были установлены. И установим недостающие.
ERROR: type «tt7» already exists
Пример полного текста ошибки:
Ошибка СУБД: ERROR: type «tt7» already exists HINT: A relation has an associated type of the same name, so you must use a name that doesn‘t conflict. |
Описание:
Данная ошибка является «плавающей» и может возникать в различных местах
Решение:
Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).
ERROR: could not read block
Ошибка при выполнении операции с информационно базой по причине: Ошибка СУБД: ERROR: could not read block ... in file «» Input/output error |
Описание ошибки:
База не запускается. Разрушились диски.
Решения:
Переносим базу на другую дисковую систему.
Разворачиваем из резервной копии.
Не удалось запустить сервер PostgreSQL
Пример полного текста ошибки:
Не удалось привязаться к адресу. Адрес уже используется. Возможно порт 5432 занят другим процессом postmaster? Система БД выключена.Не удалось запустить сервер. |
Описание:
Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию.
В этой ситуации при попытке запуска видно ошибку – сервер не запускается.
А при проверке состояния видно, что сервер работает.
netstat –tlnp | grep 5432 |
Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.
Решение:
Остановим работающий кластер сервера СУБД.
/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /var/lib/pgpro/ent—10/data stop |
Инициализируем кластер из нового каталога(если он не инициализирован).
/opt/pgpro/ent—10/bin/initdb —locale=ru_RU.UTF—8 —D /pgpro/pgdata |
Запустим из нового каталога.
/opt/pgpro/ent—10/bin/pg_ctl —locale=ru_RU.UTF—8 —D /pgpro/pgdata start |
Длительный запуск 1С:Предприятия при работе с СУБД PostgreSQL
Описание:
Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.
Решение:
Такая проблема может быть связано с настройками СУБД PostgreSQL.
Рассчитаем настройки СУБД.
Описание настроек приведено на ИТС.
Выполним настройки, для этого перейдем в терминал psql:
Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):
Пример настроек:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
ALTER SYSTEM SET shared_buffers = ’96GB’; ALTER SYSTEM SET effective_cache_size = ‘288GB’; ALTER SYSTEM SET maintenance_work_mem = ’20GB’; ALTER SYSTEM SET wal_buffers = ’16MB’; ALTER SYSTEM SET default_statistics_target = 100; ALTER SYSTEM SET random_page_cost = 1.1; ALTER SYSTEM SET effective_io_concurrency = 200; ALTER SYSTEM SET work_mem = ’10GB’; ALTER SYSTEM SET max_worker_processes = 44; ALTER SYSTEM SET max_parallel_workers_per_gather = 22; ALTER SYSTEM SET temp_buffers = ‘265MB’; ALTER SYSTEM SET wal_level = ‘replica’; ALTER SYSTEM SET max_replication_slots = ‘8’; ALTER SYSTEM SET max_wal_senders = ’32’; ALTER SYSTEM SET autovaccuum = ‘on’; ALTER SYSTEM SET autovaccuum_max_workers = 16; ALTER SYSTEM SET autovacuum_naptime = ’20s’; ALTER SYSTEM SET bgwriter_delay = ’20ms’; ALTER SYSTEM SET bgwriter_lru_multiplier = 4.0; ALTER SYSTEM SET bgwriter_lru_maxpages = 400; ALTER SYSTEM SET synchronous_commit = ‘off’; ALTER SYSTEM SET checkpoint_segments = 256; ALTER SYSTEM SET checkpoint_completion_target = 0.9; ALTER SYSTEM SET min_wal_size = ‘4GB’; ALTER SYSTEM SET max_wal_size = ‘8GB’; ALTER SYSTEM SET ssl = ‘off’; ALTER SYSTEM SET max_files_per_process = 1000; ALTER SYSTEM SET standard_conforming_strings = ‘off’; ALTER SYSTEM SET escape_string_warning = ‘off’; ALTER SYSTEM SET max_locks_per_transaction = 256; ALTER SYSTEM SET max_connections = 15000; |
Из файла *xlsx загружаются в 1С иероглифы/ в файл выгружаются иероглифы.
Описание ошибки:
При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.
Также возможна проблема с кодировкой в выгружаемом файле из 1С:
Решение:
На сервере СУБД проверим и выполним настройку локали.
1. Проверим наличие локали:
2. Проверим переменную:
Корректное значение результатов выполнения команд 2, 3:
3. Если результат не соответствует, выполним:
export LANG=«ru_RU.UTF-8» |
4. Выполним:
localectl set—locale LANG=ru_RU.utf8 |
5. Выполним перезапуск серверов СУБД
When creating a new column on a table, I’m getting the following error:
ERROR: could not read block 167593 in file "pg_tblspc/16384/PG_9.4_201409291/16386/157223695.1": read only 0 of 8192 bytes
SQL state: XX001
Obviously not good, as SQL state XX001 means corrupt data. I’m not too bothered as this is not critical data and can relatively easily be re-loaded from the source.
However, after searching for similar issues, all I can see from other people is this error for ‘of relation base’, not ‘in file’. How is ‘in file’ different, and what does this mean? Is it more likely that I have a hardware issue?
Also, how can I check to see for certain that the data is corrupted?
asked May 4, 2016 at 8:59
MattMatt
4451 gold badge8 silver badges18 bronze badges
However, after searching for similar issues, all I can see from other
people is this error for ‘of relation base’, not ‘in file’. How is ‘in
file’ different, and what does this mean? Is it more likely that I
have a hardware issue?
No, it’s the same issue. The error message used to refer to the relation in older versions of PostgreSQL, but it was changed at some point (version 9.0
, probably) to refer to the corresponding file instead.
I think the switch to the new message format happened here:
commit 23dc89d2c385e8e362cb4b8186b4d4ad02242ac0
Author: Heikki Linnakangas
Date: Wed Aug 5 18:01:54 2009 +0000Improve error messages in md.c. When a filesystem operation like open() or fsync() fails, say "file" rather than "relation" when printing the filename. This makes messages that display block numbers a bit confusing. For example, in message 'could not read block 150000 of file "base/1234/5678.1"', 150000 is the block number from the beginning of the relation, ie. segment 0, not 150000th block within that segment. Per discussion, users aren't usually interested in the exact location within the file, so we can live with that. To ease constructing error messages, add FilePathName(File) function to return the pathname of a virtual fd.
answered May 4, 2016 at 11:04
Daniel VéritéDaniel Vérité
28.9k3 gold badges64 silver badges75 bronze badges
1
Ошибка субд xx001 error could not read block
PostgreSQL 9.1.2-1.1C(x64)
Ошибка СУБД — ERROR : could not read block 4200 in file «base/16400/4506195» : read only 0 of 8192 bytes.
База 1С Зарплата и кадры Бюджетного учреждения. База работает а бэкапить эта ошибка не дает.
Сам я в СУБД не специалист сразу оговорюсь,
стандартными средствами в программе PGAdmin и конфигураторе 1С данную ошибку исправить не можем
бекап последний аж месяц назад делался до отпуска может есть какой нибудь скрипт исправляющий данную ошибку. Пожалуйста помогите в моем вопросе (скриншоты прилагаю)
ВложениеРазмер
PGADMIN-ошибка резервной копии.jpg | 66.57 kb |
сохранения базы в конфигураторе.jpg | 37.4 kb |
тестирования.jpg | 52.51 kb |
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
База посыпалась
On Июнь 9th, 2014 Vitalts says:
Could not obtain information about Windows NT group/…, error 0x534. (MSSQL Server, Error: 15404)
У вас база посыпалась, по всей видимости, бэд сектора на жестком. Теперь только выяснять битые записи и восстанавливать их из бякапов или иными методами.
Из таблицы, на которой падает pg_dump, делаете выборку всех полей с лимитом и оффсетом, постепенно сужая выборку, рано или поздно доберетесь до той самой битой записи. Далее можно определить и само битое поле, но если есть бякап с этой записью то и не к чему.
Надеюсь, как мержить живую таблицу с исключением битых записей и бякапа с выборкой этих самих записей не нужно.
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
Можно подробно что нужно сделать
On Июнь 9th, 2014 Виктор Overcul says:
В PGAdmin возможность выполнять sql запросы к базе объясните подробно как нам нужно сделать выборки и т.д
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
Наймите специалиста
On Июнь 10th, 2014 Vitalts says:
Мой вам совет, наймите специалиста на эту разовую процедуру, дешевле выйдет. Ведь мало найти битые записи, нужно еще и заменить их записями из бякапов, а вы уже на простых селектах застряли.
Запросами вида:
SELECT * FROM broken_table ORDER BY id offset x LIMIT y
нужно обойти все записи в проблемной таблице сужая круг поиска при попадании в блок данных с битыми записями. Если база шибко большая, то еще и скриптовые языки задействовать для автоматизации поиска, тот же pgscript, к примеру.
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
Источник: postgresql.men
Npgsql и Postgresql: ОШИБКА: XX001: не удалось прочитать блок 2354 отношения
У меня работает служба и вставляет данные (много данных). Иногда, а это всего несколько недель, я получаю эту ошибку:
ERROR: XX001: could not read block 2354 of relation 1663/17633/17925: read only 0 of 8192 bytes.
Эта ошибка связана с соединителем Npgsql PostGresql:
SQUASHFS error: squashfs_read_data failed to read both 0X0 |Error solved | linux or ubuntu usbboot |
Exception trace: at Npgsql.NpgsqlConnector.CheckErrors() at Npgsql.NpgsqlConnector.CheckErrorsAndNotifications() at Npgsql.NpgsqlCommand.ExecuteCommand() at Npgsql.NpgsqlCommand.ExecuteNonQuery()
Если я сделаю запрос, который создаст эту ошибку внутри PGAdmin, у меня тоже будет эта ошибка. Кто-нибудь знает, почему этот запрос Insert, в котором нет ничего особенного, имеет эту ошибку? В этой таблице есть первичный ключ, но нет внешнего ключа, и я проверил вручную, эта таблица не содержит первичный ключ.
Как я могу решить эту ошибку?
Источник: question-it.com
Ошибка СУБД:
Описание ошибки: База не запускается после установки и создания. Решения: Установим версию предназначенную для работы с 1С:Предприятием. Скачать такую можно с сайта 1С (при наличии купленного ИТС и открытого доступа), или приобрести у PostgresPro. Либо проверим все ли зависимости были установлены. И установим недостающие.
ERROR: type «tt7» already exists
Ошибка СУБД :
ERROR : type « tt7 » already exists
HINT : A relation has an associated type of the same name , so you must use a name that doesn ‘ t conflict .
Описание: Данная ошибка является «плавающей» и может возникать в различных местах Решение: Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).
ERROR: could not read block
Ошибка при выполнении операции с информационно базой по причине : Ошибка СУБД : ERROR : could not read block . . . in file «» Input / output error
Описание ошибки: База не запускается. Разрушились диски. Решения: Переносим базу на другую дисковую систему. Разворачиваем из резервной копии.
Не удалось запустить сервер PostgreSQL
Не удалось привязаться к адресу . Адрес уже используется . Возможно порт 5432 занят другим процессом postmaster ? Система БД выключена . Не удалось запустить сервер .
Описание: Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию. В этой ситуации при попытке запуска видно ошибку – сервер не запускается. А при проверке состояния видно, что сервер работает.
netstat – tlnp | grep 5432
Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию. Решение: Остановим работающий кластер сервера СУБД.
/ opt / pgpro / ent — 10 / bin / pg_ctl — locale = ru_RU . UTF — 8 — D / var / lib / pgpro / ent — 10 / data stop
/ opt / pgpro / ent — 10 / bin / initdb — locale = ru_RU . UTF — 8 — D / pgpro / pgdata
/ opt / pgpro / ent — 10 / bin / pg_ctl — locale = ru_RU . UTF — 8 — D / pgpro / pgdata start
Длительный запуск 1С:Предприятия при работе с СУБД PostgreSQL
ALTER SYSTEM SET shared_buffers = ’96GB’ ;
ALTER SYSTEM SET effective_cache_size = ‘288GB’ ;
ALTER SYSTEM SET maintenance_work_mem = ’20GB’ ;
ALTER SYSTEM SET wal_buffers = ’16MB’ ;
ALTER SYSTEM SET default_statistics_target = 100 ;
ALTER SYSTEM SET random_page_cost = 1.1 ;
ALTER SYSTEM SET effective_io_concurrency = 200 ;
ALTER SYSTEM SET work_mem = ’10GB’ ;
ALTER SYSTEM SET max_worker_processes = 44 ;
ALTER SYSTEM SET max_parallel_workers_per_gather = 22 ;
ALTER SYSTEM SET temp_buffers = ‘265MB’ ;
ALTER SYSTEM SET wal_level = ‘replica’ ;
ALTER SYSTEM SET max_replication_slots = ‘8’ ;
ALTER SYSTEM SET max_wal_senders = ’32’ ;
ALTER SYSTEM SET autovaccuum = ‘on’ ;
ALTER SYSTEM SET autovaccuum_max_workers = 16 ;
ALTER SYSTEM SET autovacuum_naptime = ’20s’ ;
ALTER SYSTEM SET bgwriter_delay = ’20ms’ ;
ALTER SYSTEM SET bgwriter_lru_multiplier = 4.0 ;
ALTER SYSTEM SET bgwriter_lru_maxpages = 400 ;
ALTER SYSTEM SET synchronous_commit = ‘off’ ;
ALTER SYSTEM SET checkpoint_segments = 256 ;
ALTER SYSTEM SET checkpoint_completion_target = 0.9 ;
ALTER SYSTEM SET min_wal_size = ‘4GB’ ;
ALTER SYSTEM SET max_wal_size = ‘8GB’ ;
ALTER SYSTEM SET ssl = ‘off’ ;
ALTER SYSTEM SET max_files_per_process = 1000 ;
ALTER SYSTEM SET standard_conforming_strings = ‘off’ ;
ALTER SYSTEM SET escape_string_warning = ‘off’ ;
ALTER SYSTEM SET max_locks_per_transaction = 256 ;
ALTER SYSTEM SET max_connections = 15000 ;
Из файла *xlsx загружаются в 1С иероглифы/ в файл выгружаются иероглифы.
locale — a | grep ru_RU
echo $ LANG
ru_RU . UTF — 8
export LANG = «ru_RU.UTF-8»
localectl set — locale LANG = ru_RU . utf8
Еще можно посмотреть
Установка сервера 1С Предприятие 8.3 на Linux
Пошаговый процесс установки 1С сервера на Linux. Подготовка Linux к установке. Инсталяция дистрибутива 1С сервера. Его настройка и запуск.
Установка двух версий сервера 1С на Linux
Пошаговый процесс установки и запуска двух версий сервера 1С на Linux. Полное описание настройки второго экземпляра сервера 1С.
Администрирование серверов 1С на Linux
Привычным для нас инструментом управления кластером серверов 1С является консоль «Администрирование серверов 1С Предприятия» — «Microsoft Management Console». Данная консоль позволяет выполнять все необходимые действия по администрированию кластеров серверов 1С:Предприятия. Но, она имеет один недостаток – её невозможно использовать под ОС Linux. Но не все так плохо. Альтернативными средствами администрирования серверов 1С на Linux являются: […]
Пошаговая настройка варианта хранения файлов 1С Предприятия во внешнем NFS хранилище на ОС Linux
Ошибки публикации базы и веб сервиса на веб сервере 1C+ Apache +Linux.
Многие из нас привыкли публиковать базу или веб сервис 1С нажатием нескольких кнопок. Но не все из многих знают, что для этого необходимо запустить(от имени администратора!) конфигуратор 1С:Предприятие именно на той машине, где установлен веб сервер(а именно компонента веб-расширения 1С:Предприятия). В случае, если веб-сервер и компонента веб-расширения 1С:Предприятия установлены на машину с ОС Linux без […]
ОШИБКА 1С:ПРЕДПРИЯТИЯ «ПОТЕРЯНО СОЕДИНЕНИЕ»
У пользователя во время работы может возникать сообщение: [crayon-63a62027e5ba6758504674/] После чего рабочий режим либо восстанавливается, либо нет. В сообщении достаточно ясно описана возникшая ситуация, но необходимо понимать, что по другую сторону экрана пользователя, ландшафт системы может быть несколько сложнее, чем он себе представляет. И сервер «с которым потеряно соединение» может быть не только сервер 1С:Предприятия. […]
Ошибки на клиенте при подключении к серверу 1С на Linux. Часть 1
Рассмотрены ошибки при подключении к серверу 1С на Linux. Изложена методика поиска причин и путей их исправления
Источник: 1s-on.ru
Npgsql и Postgresql: ОШИБКА: XX001: не удалось прочитать блок 2354 отношения
У меня работает служба и вставляет данные (много данных). Иногда, а это всего несколько недель, я получаю эту ошибку:
ERROR: XX001: could not read block 2354 of relation 1663/17633/17925: read only 0 of 8192 bytes.
Эта ошибка связана с Npgsql-коннектором PostGresql:
Exception trace: at Npgsql.NpgsqlConnector.CheckErrors() at Npgsql.NpgsqlConnector.CheckErrorsAndNotifications() at Npgsql.NpgsqlCommand.ExecuteCommand() at Npgsql.NpgsqlCommand.ExecuteNonQuery()
Если я сделаю запрос, который создаст эту ошибку внутри PGAdmin, у меня тоже будет эта ошибка. Кто-нибудь знает, почему этот запрос Insert, в котором нет ничего особенного, имеет эту ошибку? В этой таблице есть первичный ключ, но нет внешнего ключа, и я проверил вручную, эта таблица не содержит первичный ключ.
Как я могу исправить эту ошибку?
задан 31 марта ’09, 13:03
Источник: stackovergo.com
Ошибка СУБД при удалении
Автор Ginayat, 26 окт 2017, 14:30
0 Пользователей и 1 гость просматривают эту тему.
Добрый день!
Имеется база Бухгалтерия гос предприятие здраво 1.0.27.1 крутится на postgresql сервере
Изначально проблема была с выгрузкой не выгружалась база выдавал ошибку через постгрес тоже
Через предприятие нашли проблемный документ который не дает выгрузить базу вот хотели удалить этот документ через интерактивное удаление тоже не помогло выдает ошибку
на скриншоте (скриншот прилагается)
С 2016 года никто не обновлял и соответственно не выгружал базу
Прошу Помочь буду признателен!
Бедный российский госсектор денег им на номральные субд не выделяют вот и приходится мучиться со всякими коварными багами, которые никто раньше в глаза не видел.
Тестирование и исправление пробовали делать?
Цитата: MuI_I_Ika от 26 окт 2017, 14:57
Бедный российский госсектор денег им на номральные субд не выделяют вот и приходится мучиться со всякими коварными багами, которые никто раньше в глаза не видел.Тестирование и исправление пробовали делать?
Да делали не помогает
А что за ошибка то, что не так с документом?
Цитата: MuI_I_Ika от 26 окт 2017, 15:13
А что за ошибка то, что не так с документом?
Не выгружается база , нашли причину из за чего не выгружается база в документе Отражение Зарплаты
Ошибка СУБД:
ERROR:could not read block 23962 in file «base/16402/340816»:Invalid argument
Это при удаление документе
А если его перезаписывать ошибка возникает?
А если распровести?
Очистить табличную часть?
А если поискать данный документ в базе и попробовать удалить непосредственно на таблице.
Естественно такие операции лучше сначала проделать на копии.
Цитата: Ginayat от 27 окт 2017, 08:59ERROR:could not read block 23962 in file «base/16402/340816»:Invalid argument
зделайте ТИИ средствами СУБД. MS SQL? Тогда
DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]
Спасибо за Сказать спасибо