1c ошибка субд 0x00040eda
Что делать?
V. Дополнительные действия
При подозрениях на ошибки жёсткого диска, на котором располагается информационная база:
- скопируйте каталог базы на другой физический диск;
- удалите все файлы и папки, кроме файла 1Cv8.1CD;
- войдите в базу с нового расположения.
VI. Нестандартные ситуации
Когда один пользователь входит в базу 1С и работает без ошибок, а у другого — сбой. В этом случае выполните очистку кэша на рабочем месте, где возникает ошибка. Подробнее здесь .
В других случаях ошибка может скрываться в платформе 1С. Поэтому, проверьте обновление и переустановите платформу на новый релиз, одновременно удалив устаревшие версии.
⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.
В базе есть Справочник. Среди реквизитов имеем 4 с типом "Хранилище данных". Сейчас наткнулся на 2 элемента этого справочника, при попытке открыть которые возникает ошибка (после чего 1С-ка закрывается):
Ошибка СУБД Interface 0c733a7c-2a1c-11ce-ade5-00aa0044773d
Ошибка возникает при любой попытке открыть\получить объект (программно или визуально). Почитал на форумах, народ пишет, что подобное решается перезагрузкой сервера - попробовал, не помогает. Так же рекомендовали настройку:
"установка ключей /PAE и /3GB в boot.ini, а так же AWE на SQL"
Но когда начал капать, то вижу, что "/PAE и /3GB в boot.ini" касается в основном проблем с Win Server 2003.
ВОПРОС - куда еще капать и как решить проблему?
(0) при чем тут ключи SQL?
Полагаю что это связано с фрагментацией памяти из-за сервера 1С.
У тебя сервер предприятия 64 бита?
Можно предположить что в поле с типом хранилище данных большой файл.
И банально не хватает памяти для запроса.
(3) Скорее всего да
(4) Я читал эту ветку
(2) ТЫ сам в (4) привел ссылку где написано:
Так вот чтобы справится приходится включать /PAE, /3GB (на системах с малым кол-вом ОЗУ). Включать в SQL Server механизм AWE (адресацию по другому).
Некоторым помогает перезагрузка (но можно пойти другим путем - простым передергиванием процесса 1c COM (из интерфейсов COM)). Но если внесены хотя бы какие-то изменения в конфу, может и не помочь.
В этом случае мне помог переход на 64-битую ОС (адресация памяти без хитрых и неучтенных механизмов /PAE и /3GB). Но нужно учитывать, что не все редакции SQL Server способны с ней работать. Без проблем Enterprise и Express Edition через механизмы в Windows под названием WoW 64 (насколько помню).
В большинтсве случаев безотказно работает переход на 64 битную ОС, 64-битный SQL Server (производительность на сервере поднимается на хорошо, к примеру на 32-итной системе я имел время закачки новой конфы из XML порядка 11 минут, с переходом на 64-бита - получил 7), и 64-битный сервер 1с:Предприятия. Клиент к сожалению только 32 битный, но это абсолютно не мешает работе.
ЗЫ: Учтите что будет требоваться 64-битный серверный HASP (читайте внимательно, как его обновить и получить, замена не бесплатная порядка 40 тыров).
ЗЫЫ: Удачи в борьбе с данной штукой))
(6) + Ток у меня и так 64 битная Win Server 2012
SQL Server 2012 тоже 64 битный
+ 128 Гигов оперативы на сервере
Я вот думаю, если затык именно на стороне 1С, то эти 2 элемента справочника просто средствами SQL удалить и все. Ссылок на них нет (это я проверил), ссылочная целостность сохраняется.
Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.
Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :
Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.
При постановке конфы обратно на поддержку архивация начинает работать нормально.
Как можно решить проблему?
(0)[Как можно решить проблему?]
invalid memory alloc request size 1174829507
видимо копать нужно от сюда
Проводил эксперимент:
1. Выгружаю конфу поставщика в cf.
2. Из цф создаю чистую базу.
3. Запускаю pg_dump - архивация проходит нормально.
4. В этой же конфе включаю возможность изменения.
5. Запускаю pg_dump - архивация проходит НЕ нормально.
(7) Был у меня клиент пару лет назад. Жаловался на похожие траблы. Поскольку ему нужно было хоть какое-то решение, то ему пришлось делать все такие штуки непосредственно в линуксе - под виндой уже не работало.
Именно с конфигой на КА 1.1 .
Если кто имеет возможность провести эксперимент (6), попробуйте и напишите о результате. На все про все нужно 15 минут на нормальном компе.
Я пробовал на WinServer 2008 R2 и Win7 .
(2) Вроде как у Postgres лимиты не маленькие :
Максимальный размер таблицы - 32 TB
(0)
Покажи скрипт, как бэкап делается.
[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?
"C:\Program Files\PostgresPro 1C\9.4\bin\pg_dump" -U postgres -F c -Z9 -c -f C:\arc\arc_pg\ara_backup.backup bs
ren C:\arc\arc_pg\ara_backup.backup bs_%f_name%.*
(15) Снятие с поддержки любой другой конфигурации также приводит к такой ошибке? Или только КА указанной версии?
(18) немного не так - если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.
з.ы. Трабл именно при снятии с "замка" и при сохранении поддержки
(18) Именно в версиях КА 1.1.107.3 и 1.1.107.4.
В КА 1.1.106 проблемы еще нет.
Попробовал уже с типовыми демоконфами КА - все так же.
Т.е проблема не в моей базе , а в конфигурации конкретной версии.
(19) Я понимаю. У нас бухгалтерия и зарплата в таком режиме поддержки уже много лет, ничего подобного никогда не возникало. Правда, и сервер приложений и СУБД на Linux(тоже много лет).
(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]
А что за ограничение в этом случае срабатывает?
(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :
(31) я бы чисто ради интереса грохнул что-нибудь из конфы, чтоб привести размер cf к 0.99Гб, и проверить еще раз бэкап. (что там есть такого, макеты с двоичными данными, какие-нибудь)
(32) да я ж и предлагаю - снять с поддержки полностью и размер в два раза упадет и проблема должна уйти, если это в ней причина.
Но это ни одного там в ней изменения нет, когда вкл изм и накидать туда макетов огромных, то будет больше, конечно.
з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием "второй копии" конфигурации, которая конфликтует с "первой" при запихивании ее в БЛОБ платформой - просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.
(40) [ просто глючит в данном случае при попытке архивации баз]
+100500
проблема Postgres, с MS SQL её нет
(40) Такая же проблема должна быть и под линуксом. Ведь лимит на размер поля у Postgres одинаковый для обоих версий.
таблицы "config invalid memory alloc request size 1174829507
можно и дальше позаниматься флюдом, но тема закрыта
т.е. дело однозначно в размере cf
BLOB побился явно. Перезагрузить конфу прямой загрузкой.
(47) попробовать можно, но в тех вариантах не помогало, на которые я ссылался, что ошибки с КА 1.1 возникали в серверном режиме.
я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде - сглючит или нет - проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый. долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что :-)
"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\BUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "BUH"
Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.
(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно - до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет
можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги
(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения - в результате cf размером 1,2 Гб.
Архивация проходит без проблем.
Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.
(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.
(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.
В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.
(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 - с остальными проблем нет. с КА 2.4 тоже проблем нет.
(79) этому косяку уже много лет.
Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки конфу, чтобы работать. С появлением 64-битной проблема ушла.
И вот опять что-то похожее.
Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки - дамп отработал без ошибок.
(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет - см (74),
а так же и другие.
(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.
(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg - описанная выше ошибка
При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле - 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.
Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.
Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) - ошибка не исчезла.
(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) - еще одно подтверждение что ограничение 1ГБ ни при чем.
(0) ровно та же проблема у меня была с УПП в 2012 году - с той же ошибкой pg_dump грохался. Стабильность - признак мастерства, чо. Сколько лет прошло, а ничего не меняется.
(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство.
Фредерик Брукс-младший
Недавно возникла эта проблема
симтомы
1. Любое действие записи вызывает данную ошибку.
2. Не грузятся обмены
3. Невозможно запустить проверку БД и выгрузку
4. Невозможно открыть конфигуратор из-за блокировки информационной базы
Собственно никаких блокировок БД не было, проверялось и в консоли сервера приложений 1с и в консоли SQL сервера
Лечение.
1. делаем бэкап (на всякий пожарный, можно и не делать у кого смешанная модель бэкапа позволяющая восстановить базу на состояние часа назад к примеру )
2. сносим базу с сервера приложений(не трогая БД на SQL сервере)
и заводим её заново (можно наверно и перезагрузить сервер приложений 8.1,
но у меня на нем крутится более 20 баз, которые работали вполне адекватно)
итого починка занимает не более 5 минут(без бэкапа)
хотя вполне возможно у меня был частный случай. но есть у меня подозрение что гребет именно сервер приложений и сама БД тут совершенно ни причем
спасибо, интересный пример
но если не запускалась проверка, то неплохобы было увидеть текст ошибки (собрать можно технологическим), тогда причина станет очевидней
(3) ПОТРЯСАЮЩЕ! А статью вы пробывали читать или ваша рекомендация отличается от приведенных рекомендаций в статье? :) ИЛИ ВЫ ПОТВЕРЖДАЕТЕ ПРАВИЛЬНОСТЬ МЕТОДА? :)
подтверждаю :) опытным путем было получено, что ошибочка вылетает
при некорректном закрытии программы пользователем (во время заполнения книги продаж в типовой бухне, например ) "Ну надоело ждать".
тока все таки лучшее перегрузить, чем сносить, если есть возможность. Был еще такой глюк с такой же ошибкой в итоге, один из пользователей ставил отбор по одному из сотрудников и вылетали все. пытались повторить на других машинах и другими пользователями, хрена. дальше все продолжают успешно работать, кроме как Невозможно запустить проверку БД и выгрузку. перегружаемси, индекируемси - те же грабли.
У нас не выгружались ни cf ни dt. Оказалось, что после некорректного заверешения сервера предприятия остался висеть процесс rphost. Выяснилось это только через неделю (когда увидели что их больше чем надо :)))). Судя по всему старый процесс блокировал запись в таблице config
У меня всегда лечится перезапуском Сервера 1С. Интересно в новой платформе 8.1.13.37 не решили эту проблему?!
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
sel ect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Он позволит узнать максимальные длины хранимых в них данных. Не рекомендуется хранить данные длиннее 100 - 200Mb.
Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"
Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)
Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется. Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки - все ОК.
Буду рад, если эти рекомендации помогут кому-нибудь еще :-)
(14) да, в отношении Config, пункты 1 и 2 как раз и позволяют бороться с размером в 1.2.21.1. Спасибо что подтвердили верность инструкции.
описанная проблема полностью описывает траблы с сифилисом который сейчас твориться у меня с базой (бекапы собственные не создаются) попробую данные здесь рекомендации.
Вопрос - а если отключить поддержку, то как ее вернуть? =) как не странно помогло (проверил на демо базе =)))
Возникла ошибка "Сеанс работы завершен администратором". Установив в boot.ini ключ /3GB ошибка устранилась. Огромное спасибо за полезную информацию.
(21) artur.antipin, аналогичная проблема. Я думаю вряд ли поможет, если 32 Gb на сервере, SQL использует 30, 1Gb погоды не сделает
Недавно у клиентов была такая проблема, просто отпала база с указанной ошибкой. MS SQL 2000 показывал базу не в состоянии Suspend, а в состоянии Offline. Понятно что наивный расчет на Online базы не оправдался и я устроил допрос.
В ходе следствия выяснилось что ничего страшного никто не делал (на самом деле) просто у части юзеров полезли избыточные блокировки, и сервер(физический) было решено перезагрузить.
После перезагрузки никто не смог войти, т.к. был Offline режим файлы базы скопировать тоже не удавалось, без меня делать детач боялись. Но так как мне ничего не оставалось я нажал детач. Сервер не много подумал и отключил базу но в списке баз отключенная база осталась не отобража имени, просто пустая строка, перезапуск сервера открылся с(!) подключенной живой базой. Но была проблема, беглый осмотр основных мест показал, что полностью упали итоги регистра Заказы покупателей( изб блокировки были связаны скорее всего с этим) в итоге пришлось их пересчитывать 2,5 часа не долго, но обычно за месяц итоги считались минут 15, значит точно упали.
КонецИстории )
з.ы. причин установить не удалось
Целый день бьюсь с этой проблемой. Пришлось потанцевать с бубном. УПП 1.2.27 Платформа 15. sql 2005. Ошибка решилась соблюдением следующей последовательности действий.
1) удаляю записи больше 120 мб в sql.
2) Снимаю базу с поддержки
3)Объединяю с типовой cf 1.2.27 без галок (одновременно ставлю на поддержку) 1.2.27 предварительно протестирована и исправлена (не знаю важно ли это, но было именно так)
Возникла аналогичная проблема "Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005" при выгрузке конфигурации из БП 1.6.24.7 на 1С 8.2, сервер SQL 2000. Вопрос решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте. :)
Тоже возникла проблема с основной конфигурацией в файловом варианте. Как посоветуете drop-нуть ConfigSave?
Ошибка: Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
1C 8.1.14 + MS SQl 2005 + Терминальник (на 3х серверах)
Ошибка возникает при любых действиях пользователя - хаотично ((( причин установить не удалось
(27) как ваша ошибка коррелирует с указанной в статье "Неопознанная ошибка"?
У вас же проблема с большей вероятностью в включенном файрволе.
(28) файрволов/антивирусов нет на сервере + Ошибка возникла без каких либо изменений в системе через год после експлуатации.
(27) Vet_ne, Не подскажете как проблема решилась, у меня тоже HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
бодаюсь пока безрезультатно.
вот выдержка из этой статьи (хоть и для 2000, но принцип тотже):
Устранение неполадок с установкой подключений
Большинство подобных неполадок в SQL Server 2000 возникает из-за проблем с протоколом TCP/IP или проверкой подлинности Windows либо сочетанием проблем обоих типов.
Внимание! Перед тем как приниматься за устранение неполадок с установкой подключений в SQL Server 2000, убедитесь, что на компьютере с SQL Server запущена служба MSSQLServer.
Запишите возвращенный IP-адрес.
4. Из командной строки выполните следующую команду (где IP address — это IP-адрес, выписанный при выполнении действия 3):
Убедитесь, что команда возвращает правильное имя сервера. Если же одна из указанных выше команд завершается сбоем, возвращает неправильное значение или истекает время ожидания для ее выполнения, значит, неправильно работает просмотр DNS или существует иная проблема, связанная с функционированием сети или маршрутизацией. Чтобы просмотреть текущие параметры DNS, запустите из командной строки следующую команду:
Чтобы устранить эту проблему, добавьте запись для сервера в файл %systemroot%\system32\drivers\etc\hosts на клиентском компьютере. Кроме того, обойти проблему можно путем установки подключения к серверу с помощью сетевой библиотеки именованных каналов.
Примечание. Необходимо включить хотя бы протокол TCP/IP и именованные каналы.
3. Откройте вкладку Псевдоним и проверьте псевдонимы, настроенные для экземпляра SQL Server.
4. Убедитесь, что в свойствах псевдонимов правильно настроены имя сервера (IP-адрес) и протокол.
Можно создать новый псевдоним для тестирования подключения по имени сервера, IP-адресу или другому протоколу.
Примечание. В более ранних версиях компонентов доступа к данным Майкрософт (MDAC) интерфейс программы сетевого клиента отличается. Таким образом, если вы не видите описанных в этой статье элементов интерфейса, установите на клиентском компьютере более новую версию компонентов MDAC.
Описание
Ошибка при выполнении операции с информационной базой
Ошибка СУБД:
XX002: ERROR: index "pg_class_relname_nsp_index" contains unexpected zero page at block 7
HINT: Please REINDEX it.
по причине:
Ошибка СУБД:
XX002: ERROR: index "pg_class_relname_nsp_index" contains unexpected zero page at block 7
HINT: Please REINDEX it.
Запрос ,который вернёт ТОП 100 самых больших таблиц с учётом индексов
create extension if not exists pgstattuple;
SEL ECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC LIM IT 100
Отдельно только индексы более 200МБ:
create extension if not exists pgstattuple;
SELECT relname AS "relation", pg_size_pretty(pg_indexes_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE pg_indexes_size(C.oid) >= 209715200 AND nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_indexes_size(C.oid) DESC
Отдельно только таблицы более 1ГБ:
create extension if not exists pgstattuple;
SELECT relname AS "relation", pg_size_pretty(pg_table_size(C.oid)) AS "total_size"
FR OM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WH ERE pg_table_size(C.oid) >= 1073741824 AND nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_table_size(C.oid) DESC
Дальше комбинируйте под свои задачи, сам принцип я думаю понятен
(4) Большое спасибо за участие, знать бы еще как с ними работать, я с постгре и запросами на Вы. Запросы на скринах делал по инфе с инета. Штатного админа нет по постгре
Как вариант - собрать полный технологический журнал и посмотреть сам запрос, на котором ошибка валится.
Технологический журнал — это средство логирования действий платформы происходящих на самом низком уровне. Данные предоставляемые технологическим журналом позволяют выявить причины «тормозов», зависаний, утечек памяти и «падений» рабочих процессов.
Содержание
Общая информация
Включение технологического журнала
Создание файла настроек
Технологический журнал является основным источником информации для всех инструментов анализа производительности платформы.
Ведение технологического журнала возможно как для сервера, так и для клиентских приложений. Так как клиентские логи и дампы, за редким исключением, не представляют практического интереса, вопрос мы будем рассматривать только со стороны сервера. Тем не менее, все сказанное ниже, будет верно и для клиента.
Технологический журнал может продуцировать два вида информации:
Включение технологического журнала
По умолчанию технический журнал включен и работает, дампы хранятся здесь:
%LOCALAPPDATA%\1C\1cv8\dumps (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\dumps)
%LOCALAPPDATA%\1C\1cv8\logs (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs)
USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.
Собираемая таким образом информация минимальна — формируются дампы минимального размера при аварийном завершении работы рабочих процессов, а в логи попадают только события SYSTEM с уровнем Error.
В большинстве случаев этой информации недостаточно, следовательно нам необходимо самостоятельно указать какую информацию мы хотим видеть в логах. Для этого необходимо создать файл настроек тех. журнала (об этом ниже) с названием logcfg.xml и разместить его в одной из подходящих директорий.
Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:
Если настроить нужно конкретную версию, то здесь (зависит от версии):
Иногда может потребовать включить тех. журнал для конкретного пользователя, из под которого запущен сервер 1С, в этом случае файл настроек следует разместить тут:
Перезагружать сервер не требуется, настройки считаются и будут применены не более чем через 60 секунд. Выключить тех. журнал еще проще — нужно переместить или переименовать файл настроек.
Создание файла настроек
Теперь перейдем к содержимому файла настроек logcfg.xml.
Этот элемент отвечает за формирование дампов памяти. Атрибуты:
location — каталог в который будут сохраняться дампы, значение этого атрибута должно отличаться от значений такого же атрибута у других элементов ( и ).
create — записывать (1) или не записывать (0) дампы.
type — тип дампа, любая комбинация (сумма) из перечисленных ниже флажков:
0 — минимальный;
1 — дополнительный сегмент данных;
2 — содержимое всей памяти процесса;
4 — данные хэндлов;
8 — оставить в дампе только информацию, необходимую для восстановления стеков вызовов;
16 — если стек содержит ссылки на память модулей, то добавить флажок флаг 64;
32 — включить в дамп память из-под выгруженных модулей;
64 — включить в дамп память, на которую есть ссылки;
128 — добавить в дамп подробную информацию о файлах модулей;
256 — добавить в дамп локальные данные потоков;
512 — включение в дамп памяти из всего доступного виртуального адресного пространства.
Компания «1С» советует использовать значение 3 (1+2), так как в большинстве случаев этого достаточно.
Этот элемент определяет каталог тех. журнала и события которые в него попадают. Таких элементов может быть несколько т.е. сервер 1С может вести сразу несколько тех. журналов с различными настройками. Тем не менее компания «1С» не рекомендует вести более 20 тех. журналов одновременно, так как это может замедлить работу системы. Может содержать внутри себя элементы и . Атрибуты:
location — каталог в который будут записываться логи, этот каталог должен быть пустым, кроме этого он не должен совпадать со значениями аналогичных атрибутов у других элементов.
history — время жизни логов, в часах.
Определяет условия, при выполнении которых событие попадает в журнал. Само условие задается следующими элементами:
eq — равно;
ne — не равно;
gt — больше;
ge — больше или равно;
lt — меньше;
le — меньше или равно;
like — соответствие маске.
Определяет условия попадания в журнал значения свойства события.
Элемент включает записи в журнал всех свойств событий.
Руководство администратора (желтая, не очень толстая книжечка) можно легко найти в электронном виде, да и бумажном оно встречается достаточно часто, так как входит во многие поставки продуктов компании 1С.
III. Тестирование и исправление
- Откройте Конфигуратор.
- Выберите пункт « Тестирование и исправление… ».
- В блоке « Проверки и режимы »: — если база большая, проверьте последовательно операции; если малого размера, то все разом:
— Проверка логической целостности;
— Проверка ссылочной целостности;
- Установите параметр « Тестирование и исправление ».
При наличии ссылок на несуществующие объекты программа по умолчанию предлагает ничего не изменять.
Рекомендация : проверьте для начала режим ссылок «Не изменять». Программа выведет найденные ссылки, и после этого примете решение, очищать их или создавать.
IV. Выгрузить dt-файл и создать новую базу
Пункт аналогичен варианту №1 с тем различием, что вы восстанавливаете не резервную копию, а сначала выгружаете dt-файл.
- Откройте Конфигуратор для ИБ, где наблюдаются ошибки.
- Через меню « Администрирование — Выгрузить информационную базу… » выполните выгрузку базы в dt-файл.
- Создайте новую информационную базу и войдите в Конфигуратор.
- Через меню « Администрирование — Загрузить информационную базу… » выполните загрузку копии базы.
II. Использование утилиты chdbfl.exe
- Найдите папку с установленной платформой 1С — например, « C:\Program Files (x86)\1cv8\8.x.xx.xxxx », где 8.x.xx.xxxx - номер релиза платформы. Или проверьте в свойствах ярлыка запуска 1С, значение «Рабочая папка».
- Откройте приложение из каталога bin, где находится искомый файл.
- Выберите файл 1Cv8.1CD, установите признак « Исправлять обнаруженные ошибки » и нажмите на кнопку « Выполнить ».
По окончанию проверки программа покажет результаты, а при возможности — исправит обнаруженные ошибки.
Варианты действий:
- Восстановить информационную базу из резервной копии (если есть).
- Использовать встроенную утилиту для проверки целостности — chdbfl.exe.
- Выполнить тестирование и исправление базы через Конфигуратор.
- Создать новую пустую базу и загрузить сформированный dt-файл.
Рассмотрим каждый из вариантов подробнее.
Рекомендация : перед любыми действиями сделайте резервную копию базы и убедитесь, что отсутствуют активные подключения пользователей.
I. Восстановление из резервной копии
Откройте Конфигуратор. Через меню « Администрирование — Загрузить информационную базу… » выполните восстановление рабочей резервной копии.
Читайте также: