Postgresql очистить временные файлы

Обновлено: 06.07.2024

Недавно попросили поднять копию одного проекта для тестов, ну и соответственно потянуть базу данных как есть из боя (pg_basebackup). Выяснилось, что физический размер базы составил 505 GB, что само по себе слегка удивило, не то, чтобы данных там было мало. Много, но не настолько.

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

На этом можно было бы закончить рассказ, и сказать, что после VACUUM FULL физический размер базы данных уменьшился на 104 Gb и все стали счастливы, расходимся.

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

Итак, начнем сначала:

есть база данных, размер 555 Gb, что по мнению является завышенной цифрой;
в данный момент проблем с ней в общем нет: база работает нормально, бекапы делаются, места везде пока достаточно, и хочется чтобы так дальше и было;
есть технологическое окно, и был проведен VACUUM FULL на всех таблицах, всех баз данных. В результате размер базы уменьшился до 451 Gb.

То что VACUUM FULL уменьшил объем базы не более чем 20% на самом деле хорошо, это значит, что не так много места использовалось неэффективно, и база данных настроена более-менее правильно. Если бы используемое место уменьшилось бы в разы, это был бы действительно повод задуматься над настройками базы.

Первичный осмотр

Первым делом смотрим на сопутствующие данные, то есть:

логи;
WAL файлы;
временные файлы;
прочий мусор.

У нас фиксируется в логах в принципе все, чтобы можно было проводить более качественный анализ работы базы данных:

При этом, очевидно, что размер лог-файлов может быть достаточно большим:

Да, размеры дневного лог-файла на высоко нагруженных базах иногда у нас превышают размер самой базы.

Поэтому не забываем про ротацию логов. Для этого устанавливаем ограничение на размер лог-файла или по времени, так параметр:

Ограничивает лог-файл одним днем, а параметры:

Отвечают за максимальный размер и возраст log-файла

Понятно, что лог-файлы должны потом доставляться на какой-нибудь бэкапный сервер там анализироваться, архивироваться и прочая, но на сервере баз данных они не должны копиться.

И да, логи желательно сохранять в понятное для вас место, например, я рекомендую хранить логи по такому пути:

WAL файлы

Или лог транзакций, кому как привычней их называть. Какие проблемы могут возникнуть с ними?

Журналы транзакций очевидно хранят транзакции, это значит, что можно открыть транзакцию и “забыть” её закрыть. Журнал начнет “копиться” с момента старта этой транзакции. Поэтому не забываем устанавливать timeout:

И только в особых случаях эти параметры увеличиваются.

Но основные проблемы с чисткой WAL файлов возникают на этапе их архивации, при включенном archive_mode, когда команда archive_command не может быть выполнена. В этом случае WAL файлы начинают копиться до момента когда архивация может сработать.

Соответственно, требуется проверить, что у нас в pg_wal (pg_xlog, для версии 9.6 и ниже) и соответствует ли количество WAL файлов параметру wal_keep_segments.

Также стоит проверить раздел где хранятся архивные файлы WAL, если они доставляются ведомому серверу отдельно.

Временные файлы

На самом деле временные файлы, создаваемые при выполнении запросов, нас интересуют мало, так как они автоматически удаляются после выполнения. Но это не точно, при падении сервера баз данных во время выполнения тяжелого запроса, который создал много временных файлов, они таки могут остаться. Правда, чтобы такое произошло, требуется, как минимум “ретроградный Меркурий”.
Основной причиной переполнения временных файлов может служить наличие связки pgbouncer + PostgreSQL и временные таблицы.
Так, у нас бизнес-аналитики любят развлекаться с аналитическими запросами с использованием временных таблиц. Как известно, временные таблицы удаляются по истечении сессии, но при использовании pgbouncer сессия в общем-то становится как бы “вечной” в пуле соединений. И если временные таблицы не удалять вручную, то их удалять никто автоматически не будет.

Как-то однажды внезапно перезагрузился тестовый сервер с PostgreSQL который до этого достаточно долго “кошмарили” разработчики и аналитики. И база данных никак не хотела стартовать, то есть, она не падала при старте, а как-то “залипала” на этапе запуска. Как оказалось, накопилось несколько десятков гигабайт временных файлов и PostgreSQL их очень долго прожевывал на старте.

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

Который вернет список всех временных таблиц текущей базы данных и их размер. Но можно просто быстро проверить, что у нас в папке pgsql_tmp:

Заодно проверить, не прошел ли “ретроградный Меркурий”.

Прочий мусор

В своей работе я сталкивался с разными артефактами криворуких админов, но массово заметил хранение каких-либо дампов базы в самой папке базы данных. Ну и система может сохранить core dump файл (postgres.core) процесса PostgreSQL при его падении. Остальной же состав файлов и папок примерно такой:

С первичным осмотром закончили и если результата нет или его мало, можно приступить к следующему этапу.

Как я писал выше, первичный осмотр не выявил проблем, все-таки боевая база. По его результатам места больше не стало. Но бывало, что размер накопившихся WAL файлов был несколько Gb, а размер всех временных таблиц как-то достиг

Некоторые спросят, а как же autovacuum, он же может быть выключен, упал и прочая. Отвечаю, включение или выключение autovacuum в моменте место нам не освободит и не займет. Им займемся позже.

Лишние объекты базы данных

Точнее неиспользуемые объекты базы данных. К ним могут относиться:

неизвестные таблицы;
неиспользуемые индексы;

Также, мне пришлось сбросить статистику, так как VACUUM FULL на всех таблицах привел к тому, что все таблицы использовались и из них читались данные. Сброс статистики выполняется командой:

Неизвестные таблицы

Мне повезло, и большинство таблиц называлось более чем вменяемо и однотипно:

И это без учета размера индексов на этих таблицах и только одна база (пусть и самая большая).

Далее, можно переименовать все таблицы по шаблону, например ‘deplecated_’ + relname, либо отключить права на чтение-запись для проектного пользователя и ждать обратной связи от пользователей и приложений. В случае чего вернуть всегда можно. А можно их просто удалить, все одно есть резервирование и судя по статистике таблицы не используются, значит в бекапе будут актуальные данные.

Итого высвобождено места: 19 Gb (на 1Gb наскребли индексы и прочие таблицы из других баз).

При этом, стоит проверить сомнительные таблицы на использование. В случае чего, сделать соответствующие организационные выводы.

Неиспользуемые индексы

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

Первичный ключ удалять точно нельзя даже если статистика показывает, что он ни разу не использовался. Уникальные индексы тоже скорее всего удалять нельзя, по крайней мере без согласования с разработкой. Тем не менее некоторые разработчики считают, что уникальные индексы работают быстрее и могут наплодить их вагон и тележку, при этом они будут проходить проверку уникальности, просто потому что в них поле id, и не создавать конфликтов при работе. Так что проверить все же стоит. Впрочем, это больше относится к производительности, потому вернемся к занимаемому месту.

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

При этом, удаление “лишних” индексов не так страшно с точки зрения данных. Но после удаления обязательно провести мониторинг и анализ медленных запросов к базе.

Общий размер составил:

Итого высвобождено места: 14 Gb.

В общем, с черновой уборкой закончили пора перейти к самой “мякоте”.

Фрагментация

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

записи хранятся в страницах таблицы по 8 kb;
при изменении записи, новая версия может быть сохранена в той же странице, если у нее достаточно для этого свободного места (см. fillfactor);
если в старой странице осталась хотя бы одна запись, то она не может быть использована для сохранения в ней новых записей.

В итоге основными “факторами” фрагментации являются:

удаление старых записей, в этом случае в странице может освободится больше места для обновлений оставшихся в ней записей, но не для новых записей;
если производятся постоянные массовые или частые изменения записей, autovacuum может не успевать очищать страницы и соответственно высвобождать резерв.

Последний пункт можно нивелировать увеличением приоритета процесса autovacuum в системе, так как по-умолчанию его приоритет понижен чтобы не мешать клиентам.

Фрагментация индексов

Следует иметь ввиду что конкурентное создание индекса замедляется относительно того как много изменений вносится в таблицу при его создании.

Фрагментация таблиц

Если с индексами еще достаточно просто, то с таблицами куда сложней, так как есть VACUUM и он имеет несколько вариаций:

Как было сказано выше, основной проблемой раздувания таблиц является полупустые страницы, то есть, если в странице, допустим было 10 строк и 6 из них мы удалили, то оставшиеся 4 строки штатно не получится “выкурить” практически никак, так как оставшееся свободное пространство в странице позволит производить запись новой версии строк прямо на месте в той же странице не отходя от кассы.

Например создадим таблицу и отключим у нее autovacuum для чистоты эксперимента:

Заполним её какими-нибудь данными:

Размер таблицы у нас получился:

Теперь немного её разрыхлим:

Возвращаем степень заполнения в 100%

Теперь погоняем массовые UPDATE:

Проверим, что у нас с размером:

Важно! командой VACUUM мы осуществляли очистку свободного места в страницах для того, чтобы можно было не выносить обновление записи за пределы страницы. Если мы не будем этого делать, то мы получим весьма печальную картину:

Сделаем несколько массовых UPDATE без VACUUM и посмотрим как изменялся размер таблицы:

Тут еще можно было бы придумать, что-то типа такого:

уплотнить записи в конце таблицы, чтобы страницы в начале таблицы стали пустыми;
очистить таблицу;
массово обновить, так чтобы уплотнение пошло в начало таблицы и освободило страницы в конце;
очистить таблицу, отрезав пустые страницы в конце.

Но так не работает, так как, например, в последней странице в таблице практически всегда есть свободное место под обновление строки в ней и она всегда останется заполненной.

Но хватит примеров, вернемся к сути.

Вариант только один: полное клонирование таблицы. Увы клонирование больших таблиц занимает время во время которого вероятность изменения данных большая. Но если есть возможность приостановить операции изменения на таблице, то можно сделать так:

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

Понятно, что пользователь при этом не должен быть SUPERUSER и не быть владельцем этой таблицы, иначе права забрать не получится.

Создаем для новой таблицы все индексы и первичный ключ. Восстанавливаем последовательности.

Поля SERIAL становятся целочисленными без последовательностей, поэтому после создания требуется перепривязать существующие последовательности от старой таблице к новой.

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

Даем права на новую таблицу для проектного пользователя:

И переименовываем таблицы:

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

Клонируем таблицу, но без данных:

Создаем триггер для таблицы test и хранимую процедуру для него:

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

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

В PostgreSQL 11 появились хранимые процедуры, поэтому воспользуемся ими для написания скрипта выгрузки данных (в противном случае потребуется использовать какой либо внешний инструмент для написания скрипта, но ни в коем случае не хранимую функцию, так как они работают в рамках одной транзакции):

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

Так же выдаем права для проектного пользователя:

После чего производим переименование. Да, в этот момент мы также столкнемся с блокировкой, но достаточно короткой, так как переименование таблицы атомарная операция, хоть их и две сразу:

И так для каждой таблицы.

Немного долго, немного неудобно, зато без эксклюзивных блокировок.

Резюме

В итоге что мы получили:

на уплотнении таблиц: 104 Gb
уборка мусора: 33 Gb

Мы сэкономили 24,6 % дискового пространства относительно начального размера базы данных.

Sometimes I run a Postgres query and it takes 30 seconds. Then, I immediately run the same query and it takes 2 seconds. It appears that Postgres has some sort of caching. Can I somehow see what that cache is holding? Can I force all caches to be cleared for tuning purposes?

I'm basically looking for a Postgres version of the following SQL Server command:

But I would also like to know how to see what is actually contained in that buffer.

508k 117 117 gold badges 934 934 silver badges 1081 1081 bronze badges 36.3k 61 61 gold badges 174 174 silver badges 252 252 bronze badges

11 Answers 11

You can see what's in the PostgreSQL buffer cache using the pg_buffercache module. I've done a presentation called "Inside the PostgreSQL Buffer Cache" that explains what you're seeing, and I show some more complicated queries to help interpret that information that go along with that.

It's also possible to look at the operating system cache too on some systems, see [pg_osmem.py] for one somewhat rough example.

There's no way to clear the caches easily. On Linux you can stop the database server and use the drop_caches facility to clear the OS cache; be sure to heed the warning there to run sync first.

14.9k 1 1 gold badge 32 32 silver badges 27 27 bronze badges Is it possible to simply bypass the caching within a single session? We often need to performance test different queries and this caching makes it very difficult to assess whether one method is better than another (except when comparing the cached performance!)

I haven't seen any commands to flush the caches in PostgreSQL. What you see is likely just normal index and data caches being read from disk and held in memory. by both postgresql and the caches in the OS. To get rid of all that, the only way I know of:

What you should do is:

Shutdown the database server (pg_ctl, sudo service postgresql stop , sudo systemctl stop postgresql , etc.)
echo 3 > /proc/sys/vm/drop_caches This will clear out the OS file/block caches - very important though I don't know how to do that on other OSs. (In case of permission denied, try sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" as in that question)
Start the database server (e.g. sudo service postgresql start , sudo systemctl start postgresql )

895 2 2 gold badges 10 10 silver badges 10 10 bronze badges

Greg Smith's answer about drop_caches was very helpful. I did find it necessary to stop and start the postgresql service, in addition to dropping the caches. Here's a shell script that does the trick. (My environment is Ubuntu 14.04 and PostgreSQL 9.3.)

I tested with a query that took 19 seconds the first time, and less than 2 seconds on subsequent attempts. After running this script, the query once again took 19 seconds.

3,892 2 2 gold badges 26 26 silver badges 32 32 bronze badges

I use this command on my linux box:

It completely gets rid of the cache.

6,301 7 7 gold badges 35 35 silver badges 37 37 bronze badges If Postgresql version is not 9.0: sync; sudo service postgresql stop; echo 1 > /proc/sys/vm/drop_caches; sudo service postgresql start @rusllonrails That will only work if the service is named postgresql , which may not be the case. I think, sync should be done after stopping the server, immediately before drop_caches , as Postgres can write something during stop process again.

Yes, postgresql certainly has caching. The size is controlled by the setting shared_buffers. Other than that, there is as the previous answer mentions, the OS file cache which is also used.

If you want to look at what's in the cache, there is a contrib module called pg_buffercache available (in contrib/ in the source tree, in the contrib RPM, or wherever is appropriate for how you installed it). How to use it is listed in the standard PostgreSQL documentation.

There are no ways to clear out the buffer cache, other than to restart the server. You can drop the OS cache with the command mentioned in the other answer - provided your OS is Linux.

21.4k 4 4 gold badges 52 52 silver badges 42 42 bronze badges

I had this error.

psql:/cygdrive/e/test_insertion.sql:9: ERROR: type of parameter 53 (t_stat_gardien) does not match that when preparing the plan (t_stat_avant)

I was looking for flushing the current plan and a found this:

I had this between my inserts and it solves my problem.

15.4k 26 26 gold badges 71 71 silver badges 85 85 bronze badges The right syntax is DISCARD PLANS; . And, as documentation states: "DISCARD releases internal resources associated with a database session".

Yes, it is possible to clear both the shared buffers postgres cache AND the OS cache. Solution bellow is for Windows. others have already given the linux solution.

As many people already said, to clear the shared buffers you can just restart Postgres (no need to restart the server). But just doing this won't clear the OS cache.

To clear the OS cache used by Postgres, after stopping the service, use the excelent RamMap (https://technet.microsoft.com/en-us/sysinternals/rammap), from the excelent Sysinternals Suite. Once you execute RamMap, just click "Empty"->"Empty Standby List" in the main menu.

Restart Postgres and you'll see now your next query will be damm slow due to no cache at all.

You can also execute the RamMap without closing Postgres, and probably will have the "no cache" results you want, since as people already said, shared buffers usually gives little impact compared to the OS cache. But for a reliable test, I would rather stop postgres as all before clearing the OS cache to make sure.

Note: AFAIK, I don't recommend clearing the other things besides "Standby list" when using RamMap, because the other data is somehow being used, and you can potentially cause problems/loose data if you do that. Remember that you are clearing memory not only used by postgres files, but any other app and OS as well.

Иногда я запускаю запрос Postgres, он занимает 30 секунд. Затем я немедленно запускаю тот же запрос и занимает 2 секунды. Похоже, что Postgres имеет какое-то кэширование. Могу ли я как-нибудь понять, что держит этот кеш? Могу ли я заставить все кеши очищаться для настройки?

Примечание. В основном я ищу версию postgres следующей команды SQL Server:

Но я также хотел бы знать, как увидеть, что на самом деле содержится в этом буфере.

Спасибо за любую помощь.

спросил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

Вы можете увидеть, что в кеше буфера PostgreSQL, используя модуль pg_buffercache. Я сделал презентацию под названием " Внутри буфера буферов PostgreSQL", которая объясняет, что вы видите, и я показываю несколько более сложных запросов, чтобы помочь интерпретировать эту информацию, которая согласуется с этим.

В некоторых системах также можно посмотреть кеш операционной системы, см. pg_osmem.py для одного довольно грубого примера.

Невозможно легко очистить кэши. В Linux вы можете остановить сервер базы данных и использовать средство drop_caches для очистки кеша ОС; не забудьте прислушаться к предупреждению, чтобы сначала выполнить синхронизацию.

ответил(а) 2020-03-07T14:45:54.785551+03:00 1 год, 8 месяцев назад

Я не видел никаких команд для очистки кешей в PostgreSQL. То, что вы видите, скорее всего, просто нормальный индекс и кэши данных, которые считываются с диска и хранятся в памяти. как postgresql, так и кэша в ОС. Чтобы избавиться от всего этого, единственный способ, которым я знаю:

Что вам нужно сделать:

ответил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

Я использую эту команду в своем linux окне:

Он полностью избавляется от кеша.

ответил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

Ответ Грега Смита о drop_caches был очень полезным. Я счел необходимым остановить и запустить службу postgresql, в дополнение к отбрасыванию кешей. Здесь находится оболочка script, которая делает трюк. (Моя среда - Ubuntu 14.04 и PostgreSQL 9.3.)

Я тестировал с запросом, который занял 19 секунд в первый раз и менее 2 секунд при последующих попытках. После запуска этого script запрос снова занял 19 секунд.

ответил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

У меня была эта ошибка.

psql:/cygdrive/e/test_insertion.sql: 9: ОШИБКА: тип параметра 53 (t_stat_gardien) не соответствует тому, что при подготовке плана (T_stat_avant)

Я искал текущий план и нашел это:

У меня было это между моими вставками, и это решает мою проблему.

ответил(а) 2020-03-27T14:45:16.419802+03:00 1 год, 8 месяцев назад

Да, postgresql, безусловно, имеет кеширование. Размер контролируется настройкой shared_buffers. Помимо этого, как упоминается в предыдущем ответе, используется также кеш файл ОС.

Если вы хотите посмотреть, что в кеше, есть доступный модуль, называемый pg_buffercache, доступный (в contrib/в исходном дереве, в Contrib RPM или везде, где это необходимо для того, как вы его установили). Как его использовать, он указан в стандартной документации PostgreSQL.

Невозможно очистить буферный кеш, кроме перезапуска сервера. Вы можете отбросить кеш OS с помощью команды, упомянутой в другом ответе, - если ваша ОС - Linux.

ответил(а) 2020-03-20T14:55:24.437231+03:00 1 год, 8 месяцев назад ответил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

Существует модуль pg_buffercache для просмотра кэша shared_buffers . И в какой-то момент мне нужно было отбросить кеш, чтобы выполнить некоторые тесты производительности на "холодном" кеше, поэтому я написал расширение pg_dropcache, которое делает именно это, Пожалуйста, проверьте это.

ответил(а) 2020-03-07T14:34:16+03:00 1 год, 8 месяцев назад

Да, можно очистить и общий буфер кеша postgres И кэш операционной системы. Решение ниже для Windows. другие уже дали решение linux.

Как уже говорили многие, чтобы очистить общие буферы, вы можете просто перезапустить Postgres (нет необходимости перезапускать сервер). Но просто это не очистит кэш ОС.

Чтобы очистить кэш ОС, используемый Postgres, после остановки службы используйте превосходный RamMap (https://technet.microsoft.com/en-us/sysinternals/rammap), из превосходной сюиты Sysinternals.
После того, как вы запустите RamMap, просто нажмите "Пустой" → "Пустой резервный список" в главном меню.

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

Вы также можете выполнить RamMap без закрытия Postgres и, вероятно, будете иметь нулевые результаты без кеша, так как, как уже говорили люди, общие буферы обычно мало влияют по сравнению с кешем ОС. Но для надежного теста я предпочел бы остановить postgres, как и все, прежде чем очистить кэш ОС, чтобы убедиться.

Примечание: AFAIK, я не рекомендую очищать другие вещи, кроме "Резервного списка" при использовании RamMap, потому что другие данные каким-то образом используются, и вы можете потенциально вызвать проблемы/потерять данные, если вы это сделаете. Помните, что вы очищаете память, которую не только используют файлы postgres, но и любое другое приложение и ОС.

это значит, что 1С не убрала за собой временную таблицу. PostgreSQL автоматически чистит такие таблицы автовакумом, но пока он доберется до проблемы может пройти много времени. Были случаи, когда лог-файлы забивали диск, вызывая падение СУБД.

Перед запуском сделайте бэкап и остановите 1C сервер!

Специальные предложения

Спасибо. Зарешаю эту проблему на одном сервере сегодня вечерком.

Просмотры 16996

Загрузки 9

Рейтинг 3

Создание 18.05.14 03:09

Обновление 21.08.14 21:01

№ Публикации 280074

Тип файла Приложение (exe)

Конфигурация Конфигурации 1cv8

Операционная система Linux

Вид учета Не имеет значения

Доступ к файлу Абонемент ($m)

Код открыт Не указано

См. также

Универсальный редактор данных (УРД) Промо

Универсальный редактор данных (УРД) - это лучший инструмент в своем классе, который позволяет редактировать реквизиты и движения объектов

1 стартмани

27.08.2021 5960 124 Adeptus 51

Изыскания на тему записи в регистр сведений

1 стартмани

21.09.2021 4580 0 METAL 57

Доп. панель Alt+Z

Панель, вызываемая для объекта комбинацией клавиш Alt+Z (для документа, справочника, плана вида характеристик, плана счетов и т.д.). Возможности: Редактор всех реквизитов, таблиц и движений, Анализ прав к объекту, Поиск ссылок на объект с фильтрами, Сторно движений документа, Выгрузка/загрузка текущего объекта между базами. Подключается как Расширение.

2 стартмани

24.06.2021 8093 100 sapervodichka 57

Мастер создания копии информационной базы для отчетности

Прототип инструмента для подготовки реплики в режиме только для чтения к использованию. Позволяет использовать "read-only" реплики как обычные информационные базы 1С.

10 стартмани

28.08.2020 9530 7 YPermitin 13

Удаление и/или копирование сохраненных в 1С настроек (например настроек печати табличных форм) Промо

Иногда нужно удалить сохраненную в 1С "покореженную" настройку или скопировать "удачную" другому пользователю.

1 стартмани

01.09.2012 66858 1378 AnryMc 46

Оптимизация размера изображений из присоединенных файлов УТ 11.4

5 стартмани

10.07.2020 8796 5 Neti 4

Создание *.dt файла из рабочей базы на сервере 1С без завершения работы пользователей

Предлагаемая обработка создает *.dt файл (выгрузку ИБ) из рабочей базы на сервере 1С:Предприятие 8.3 без завершения работы пользователей.

1 стартмани

19.01.2020 19543 98 Sedaiko 20

Транслятор запросов 1С в SQL

Инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.

10 стартмани

07.01.2020 28106 222 YPermitin 89

Очистка кэша 1С 8 (8.0, 8.1, 8.2, 8.3). Грамотная чистка кэша 1С с сохранением настроек. Промо

Эффективное средство для устранения ошибок, возникающих в локальном кэше 1С на клиенте, которым легко сможет воспользоваться пользователь с любым уровнем знаний. Wsf-скрипт, созданный на стандартном языке автоматизации Windows - "WSH JScript", очищает кэш 1С просто, быстро и безопасно. Кроме варианта, очищающего кэш текущего пользователя, имеется также вариант для чистки кэша 1С всех пользователей терминального-сервера.

1 стартмани

04.11.2018 54158 529 Eugen-S 35

Работа с базами данных 1С в SQL Server Management Studio (Расширение для SSMS)

Расширение позволяет просматривать связи объектов метаданных и таблиц БД, сгруппированные данные (по группам метаданных) об используемом дисковом пространстве и выполнять трансляцию SQL текста запроса в термины 1С. И бонусом - при наведении курсора мыши на таблицу или поле показывает назначение объекта в терминах 1С.

10 стартмани

27.11.2019 17309 46 akpaevj 46

Командный интерпретатор для 1С

Инструмент для выполнения команд CMD / PowerShell из 1С.

2 стартмани

15.11.2019 18592 35 YPermitin 41

Быстрая реструктуризация базы данных

Внешняя обработка для быстрой реструктуризации клиент-серверной базы данных. Способ ускорения реструктуризации - замена таблиц большого объема пустыми копиями перед проведением обновления БД и возврат к исходным таблицам после обновления с предварительной корректировкой их структуры. Полностью автоматизировано создание и выполнение всех требуемых скриптов SQL. Представлены версии обработки для обычных форм (1С:Предприятие 8.2 (8.2.19.130)) и управляемого приложения (1С:Предприятие 8.3 (8.3.9.1818)).

1 стартмани

05.11.2019 23261 103 dmitrydemenew 39

Легкое и гибкое управление списком доступных баз 1С у пользователей Промо

Когда в локальной сети много пользователей, а еще большое количество различных баз и при этом каждому нужны свои, то администрирование этого зоопарка превращается в АД! Этот комплекс позволяет централизованно управлять списком доступных баз в разрезе пользователей. За пару кликов можно добавить или убрать базу у всех пользователей.

7 стартмани

05.12.2018 21998 22 RomikR 9

Закрытие незавершенных сеансов

Как удалять потерянные сеансы пользователей, чтобы они не мешали работе. Обработка протестирована на платформе версии 8.3.13.1644.

1 стартмани

20.09.2019 28280 103 AnatolPopov 12

Блин, мы забыли включить регламентные задания…

Привет, Инфостарт! Сегодня расскажу, как я решил проблему с выключенными регламентными заданиями в рабочих базах. Желая исключить человеческий фактор и минимизировать количество ошибок, я написал небольшую конфигурацию. В конфигурации два регламентных задания. Первое периодически подключается к кластеру и сохраняет текущие параметры: имя, Сервер БД, базу СУДБ, блокировки входа и регламентных заданий и т.д. Второе задание периодически проверяет эти параметры на ошибки.

1 стартмани

08.04.2019 25153 19 slozhenikin_com 37

Методика оптимизации программного кода 1С: проведение документов

Описание простого метода анализа производительности программного кода 1С, способов его оптимизации и оценки результатов в виде числовых показателей прироста производительности. Не требует сторонних программных продуктов, используются только типовые возможности платформ 1С. Методика проверена на линейке платформ начиная с 1С:Предприятие 8.2 (обычные формы, управляемые формы). Позволяет ускорить проведение проблемных документов в 3 и более раз, провести проверку корректности формирования проводок оптимизированным кодом и подтвердить результаты оптимизации реальными замерами производительности в режиме предприятия. К публикации приложены демонстрационные базы для режимов обычного и управляемого приложения на платформе 1С:Предприятие 8.3 (8.3.9.2033).

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