Транзакции в PostgreSQL версии 8.0


Оглавление (нажмите, чтобы открыть):

Вложенные транзакции в postgresql 8.2?

Я работаю над скриптами, которые применяют обновления схемы базы данных. Я настроил все мои сценарии обновления SQL, используя start transaction/commit. Я передаю эти сценарии в psql в командной строке.

Теперь мне нужно применить несколько сценариев одновременно и в одной транзакции. Пока единственное решение, которое я придумал, — удалить начальную транзакцию/фиксацию из исходного набора сценариев, а затем объединить их в новый блок транзакции/фиксации начала. Я пишу perl-скрипты, чтобы сделать это на лету.

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

Есть ли способ сделать или имитировать вложенные транзакции для этой цели? У меня есть настройки, которые автоматически срабатывают при любой ошибке, поэтому мне не нужно продолжать транзакцию верхнего уровня, если какой-либо из нижних не работает.

У вас есть возможность использовать вложенные транзакции внутри postgresql с помощью SavePoints.

Возьмите этот пример кода:

Возможно, это поможет вам немного.

Я закончил «решение» моей проблемы вне диапазона — я использую perl script для повторной работы входных скриптов, чтобы устранить их начальные транзакции/фиксации вызовов, а затем направить их все в один файл, который получает он сам начинает транзакцию/фиксацию.

15 полезных команд PostgreSQL

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

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

Получение информации о базе данных

Размер базы данных

Чтобы получить физический размер файлов (хранилища) базы данных, используем следующий запрос:

Результат будет представлен как число вида 41809016 .

current_database() — функция, которая возвращает имя текущей базы данных. Вместо неё можно ввести имя текстом:

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

В результате получим информацию вида 40 Mb .

Перечень таблиц

Иногда требуется получить перечень таблиц базы данных. Для этого используем следующий запрос:

information_schema — стандартная схема базы данных, которая содержит коллекции представлений (views), таких как таблицы, поля и т.д. Представления таблиц содержат информацию обо всех таблицах баз данных.

Запрос, описанный ниже, выберет все таблицы из указанной схемы текущей базы данных:

В последнем условии IN можно указать имя определенной схемы.

Размер таблицы

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

Функция pg_relation_size возвращает объём, который занимает на диске указанный слой заданной таблицы или индекса.

Имя самой большой таблицы

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

Для того, чтобы вывести информацию о самой большой таблице, ограничим запрос с помощью LIMIT :

relname — имя таблицы, индекса, представления и т.п.
relpages — размер представления этой таблицы на диске в количествах страниц (по умолчанию одна страницы равна 8 Кб).
pg_class — системная таблица, которая содержит информацию о связях таблиц базы данных.

Перечень подключенных пользователей

Чтобы узнать имя, IP и используемый порт подключенных пользователей, выполним следующий запрос:

Активность пользователя

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

Работа с данными и полями таблиц

Удаление одинаковых строк

Если так получилось, что в таблице нет первичного ключа (primary key), то наверняка среди записей найдутся дубликаты. Если для такой таблицы, особенно большого размера, необходимо поставить ограничения (constraint) для проверки целостности, то удалим следующие элементы:

  • дублирующиеся строки,
  • ситуации, когда одна или более колонок дублируются (если эти колонки предполагается использовать в качестве первичного ключа).

Рассмотрим таблицу с данными покупателей, где задублирована целая строка (вторая по счёту).

Удалить все дубликаты поможет следующий запрос:

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

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

18 ноября – 20 декабря, Москва, 43 990 ₽


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

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

Если данные важны, то сначала нужно найти записи с дубликатами:

Перед удалением такие записи можно перенести во временную таблицу или заменить в них значение customer_id на другое.

Общая форма запроса на удаление описанных выше записей выглядит следующим образом:

Безопасное изменение типа поля

Может возникнуть вопрос о включении в этот список такой задачи. Ведь в PostgreSQL изменить тип поля очень просто с помощью команды ALTER . Давайте для примера снова рассмотрим таблицу с покупателями.

Для поля customer_id используется строковый тип данных varchar . Это ошибка, так как в этом поле предполагается хранить идентификаторы покупателей, которые имеют целочисленный формат integer . Использование varchar неоправданно. Попробуем исправить это недоразумение с помощью команды ALTER :

Но в результате выполнения получим ошибку:

ERROR: column “customer_id” cannot be cast automatically to type integer
SQL state: 42804
Hint: Specify a USING expression to perform the conversion.

Это значит, что нельзя просто так взять и изменить тип поля при наличии данных в таблице. Так как использовался тип varchar , СУБД не может определить принадлежность значения к integer . Хотя данные соответствуют именно этому типу. Для того, чтобы уточнить этот момент, в сообщении об ошибке предлагается использовать выражение USING , чтобы корректно преобразовать наши данные в integer :

В результате всё прошло без ошибок:

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

Например, преобразуем поле customer_id обратно в varchar , но с преобразованием формата данных:

В результате таблица примет следующий вид:

Поиск «потерянных» значений

Будьте внимательны при использовании последовательностей (sequence) в качестве первичного ключа (primary key): при назначении некоторые элементы последовательности случайно пропускаются, в результате работы с таблицей некоторые записи удаляются. Такие значения можно использовать снова, но найти их в больших таблицах сложно.

Рассмотрим два варианта поиска.

Первый способ
Выполним следующий запрос, чтобы найти начало интервала с «потерянным» значением:

В результате получим значения: 5 , 9 и 11 .

Если нужно найти не только первое вхождение, а все пропущенные значения, используем следующий (ресурсоёмкий!) запрос:

В результате видим следующий результат: 5 , 9 и 6 .

Второй способ
Получаем имя последовательности, связанной с customer_id :

И находим все пропущенные идентификаторы:

Подсчёт количества строк в таблице

Количество строк вычисляется стандартной функцией count , но её можно использовать с дополнительными условиями.

Общее количество строк в таблице:

Количество строк при условии, что указанное поле не содержит NULL :

Количество уникальных строк по указанному полю:

Использование транзакций

Транзакция объединяет последовательность действий в одну операцию. Её особенность в том, что при ошибке в выполнении транзакции ни один из результатов действий не сохранится в базе данных.

Мастер Йода рекомендует:  Программирование для начинающих – куда сделать первый шаг

Начнём транзакцию с помощью команды BEGIN .

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

А чтобы применить — команду COMMIT .

Просмотр и завершение исполняемых запросов

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

Для того, чтобы остановить конкретный запрос, выполним следующую команду, с указанием id процесса (pid):

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

Работа с конфигурацией

Поиск и изменение расположения экземпляра кластера

Возможна ситуация, когда на одной операционной системе настроено несколько экземпляров PostgreSQL, которые «сидят» на различных портах. В этом случае поиск пути к физическому размещению каждого экземпляра — достаточно нервная задача. Для того, чтобы получить эту информацию, выполним следующий запрос для любой базы данных интересующего кластера:

Изменим расположение на другое с помощью команды:

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

Получение перечня доступных типов данных


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

typname — имя типа данных.
typlen — размер типа данных.

Изменение настроек СУБД без перезагрузки

Настройки PostgreSQL находятся в специальных файлах вроде postgresql.conf и pg_hba.conf . После изменения этих файлов нужно, чтобы СУБД снова получила настройки. Для этого производится перезагрузка сервера баз данных. Понятно, что приходится это делать, но на продакшн-версии проекта, которым пользуются тысячи пользователей, это очень нежелательно. Поэтому в PostgreSQL есть функция, с помощью которой можно применить изменения без перезагрузки сервера:

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

Мы рассмотрели команды, которые помогут упростить работу разработчикам и администраторам баз данных, использующим PostgreSQL. Но это далеко не все возможные приёмы. Если вы сталкивались с интересными задачами, напишите о них в комментариях. Поделимся полезным опытом!

SET TRANSACTION

Synopsis

Description

The SET TRANSACTION command sets the characteristics of the current transaction. It has no effect on any subsequent transactions. SET SESSION CHARACTERISTICS sets the default transaction characteristics for subsequent transactions of a session. These defaults can be overr >SET TRANSACTION for an individual transaction.

The available transaction characteristics are the transaction isolation level and the transaction access mode (read/write or read-only).

The isolation level of a transaction determines what data the transaction can see when other transactions are running concurrently:

A statement can only see rows committed before it began. This is the default.

All statements of the current transaction can only see rows committed before the first query or data-modification statement was executed in this transaction.

The SQL standard defines two additional levels, READ UNCOMMITTED and REPEATABLE READ. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED, while REPEATABLE READ is treated as SERIALIZABLE.

The transaction isolation level cannot be changed after the first query or data-modification statement ( SELECT, INSERT, DELETE, UPDATE, FETCH, or COPY) of a transaction has been executed. See Chapter 12 for more information about transaction isolation and concurrency control.

The transaction access mode determines whether the transaction is read/write or read-only. Read/write is the default. When a transaction is read-only, the following SQL commands are disallowed: INSERT, UPDATE, DELETE, and COPY FROM if the table they would write to is not a temporary table; all CREATE, ALTER, and DROP commands; COMMENT, GRANT, REVOKE, TRUNCATE; and EXPLAIN ANALYZE and EXECUTE if the command they would execute is among those listed. This is a high-level notion of read-only that does not prevent all writes to disk.

Notes

If SET TRANSACTION is executed without a prior START TRANSACTION or BEGIN, it will appear to have no effect, since the transaction will immediately end.

It is possible to dispense with SET TRANSACTION by instead specifying the desired transaction_modes in BEGIN or START TRANSACTION.

The session default transaction modes can also be set by setting the configuration parameters default_transaction_isolation and default_transaction_read_only. (In fact SET SESSION CHARACTERISTICS is just a verbose equivalent for setting these variables with SET.) This means the defaults can be set in the configuration file, via ALTER DATABASE, etc. Consult Section 16.4 for more information.

Compatibility

In the SQL standard, there is one other transaction characteristic that can be set with these commands: the size of the diagnostics area. This concept is specific to embedded SQL, and therefore is not implemented in the PostgreSQL server.

The SQL standard requires commas between successive transaction_modes, but for historical reasons PostgreSQL allows the commas to be omitted.

Транзакции в Postgresql на C# при помощи Npgsql

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

sConn и trans — глобально описанные подключение к БД и транзакция. При создании формы Select выполняется такой код:

И вот, например, в первом приложении я выполняю такой код:

Уровень изоляции — ReadUncommitted, то есть если я сейчас изменю в другой транзакции данные, то я увижу это изменение внутри выше описанной транзакции. Проверяем. В другом приложении выполняю такой код:

Но! Нажав на кнопку «вывести баланс аккаунтов» из 1 приложения (1 транзакция), я получаю неизмененную информацию. Но ведь изоляция уровня ReadUncommitted. Как сделать так, чтобы 1 приложение увидело изменения?

Вложенные транзакции в postgresql 8.2?

Я работаю над сценариями, которые применяют обновления схемы базы данных. Я настроил все мои сценарии обновления SQL, используя start transaction / commit. Я передаю эти скрипты в psql в командной строке.

Теперь я должен применять несколько сценариев одновременно и в одной транзакции. Пока единственное решение, которое я придумал, – удалить начальную транзакцию / фиксацию из исходного набора сценариев, а затем объединить их в новый блок транзакции / фиксации начала. Я пишу perl-скрипты, чтобы сделать это на лету.

Эффективно я хочу вложенные транзакции, которые я не могу понять, как это сделать в postgresql.

Есть ли способ сделать или имитировать вложенные транзакции для этой цели? У меня есть настройки, которые автоматически срабатывают при любой ошибке, поэтому мне не нужно продолжать транзакцию верхнего уровня, если какой-либо из нижних не работает.

У вас есть возможность использовать вложенные транзакции внутри postgresql с помощью SavePoints.

Возьмите этот пример кода:

Может быть, это поможет вам немного.

Я закончил «решение» моей проблемы вне диапазона – я использую Perl-скрипт для повторной работы входных скриптов, чтобы устранить их вызовы транзакции / фиксации на запуск, а затем направить их все в один файл, который получает свою собственную транзакцию начала / совершить.

PostgreSQL для 1С

Сергей Ярастов

Вопросу, какая же СУБД — Postgresql или MS SQL для 1С является наиболее оптимальной, посвящено множество статей. В этой статье мы рассмотрим шаги оптимизации обоих. Каждая СУБД вендора имеет как собственные рекомендации по настройке, так и рекомендации фирмы 1С. Следует отметить, что в зависимости от оборудования, конфигурации серверов и количества пользователей, задающих разную нагрузку, детали процесса оптимизации СУБД под 1С и реализации рекомендаций могут меняться.

Часть 1. 1С на PostgreSQL

Часть 2. 1С на MS SQL Server

Настройка PostgreSQL под 1С


Опыт эксплуатации баз 1С на PostgreSQL показал, что наибольшей производительности и оптимальной работы 1С и PostgreSQL удалось добиться на linux, поэтому желательно использовать именно ее. Но вне зависимости от операционной системы, важно помнить, что настройки, указанные по умолчанию при установке PostgreSQL, предназначены только для запуска сервера СУБД. Ни о какой промышленной эксплуатации речи идти не может! Следующим шагом после запуска станет оптимизация PostgreSQL под 1С:

  • Для начала отключаем Energy Saving (в противном случае могут непредсказуемо вырасти задержки ответов из БД) и запрещаем своппинг разделяемой памяти.
  • Настраиваем основные параметры сервера СУБД (рекомендации по настройке описаны достаточно подробно, как на официальном сайте вендора, так и компанией 1С, поэтому остановимся только на самых важных).
  • В типовых рекомендациях компании 1С предлагается отключать механизмы HyperThreading. Но тестирование Postgres-pro на серверах, с включенной SMT (simultaneous multi threading), показало другие результаты.
Мастер Йода рекомендует:  Путь к мастерству создаём блокировщик веб-сайтов на Python

Установка параметра shared_buffers в RAM/4 является рекомендацией по умолчанию, но пример Sql Server говорит о том, что чем больше памяти ему выделяется, тем лучше его производительность (при отключенном сбросе страниц в файл подкачки). То есть, чем больше страниц данных располагаются в оперативной памяти, тем меньше обращений к диску. Возникает вопрос: почему такой маленький кэш? Ответ прост: если shared_buffers большой, то часть неиспользуемых страниц свопируется на диск. Но как отследить момент, когда сброс прекратится, и показатель параметра будет оптимальным? Для достижения и выхода на оптимальный показатель shared_buffers, его значение необходимо поднимать на продуктиве ежедневно (по возможности) с определенным шагом прироста и смотреть, в какой момент начнется сброс страниц на диск (увеличится своп).

  • Помимо этого, на «большой параметр» негативно влияет работа с множеством мелких страниц, которые по умолчанию имеют размер 8Кб. Работа с ними увеличивает накладные расходы. Что можно с этим сделать для оптимизации под 1С? В версии postgreSQL 9.4 появился параметр huge_pages, который можно включить, но только в Linux. По умолчанию включаются огромные страницы с размером по умолчанию 2048 kB. Дополнительно поддержку данных страниц необходимо включить в ОС. Таким образом, оптимизировав структуру хранения, можно выйти на больший показатель shared_buffers.
  • work_mem = RAM/32..64 или 32MB..128MB Задает объем памяти для каждой сессии, который будет использоваться для внутренних операций сортировки, объединения и пр., прежде чем будут задействованы временные файлы. При превышении этого объема, сервер будет использовать временные файлы на диске, что может существенно снизить скорость обработки запросов. Данный параметр используется при выполнении операторов: ORDER BY, DISTINCT, соединения слиянием и пр.
  • Посчитать дополнительно данный параметр можно следующим образом: (Общая память shared_buffers – память на другие программы) / число активных соединений. Это значение можно уменьшать, следя за количеством создаваемых временных файлов. Такую статистику по размеру и количеству временных файлов можно получить из системного представления pg_stat_database.
  • effective_cache_size = RAM — shared_buffers основная задача этого параметра подсказать оптимизатору запроса, какой способ получения данных выбрать: полный просмотр или сканирование по индексу. Чем выше значение параметра, тем больше вероятность использования сканирования по индексу. При этом сервер не учитывает, что данные при выполнении запроса могут оставаться в памяти, и следующему запросу не надо их поднимать с диска.

    Установка PostgreSQL

    Установка 1С на PostgreSQL под Windows – достаточно простой процесс. При запуске установочного пакета необходимо указать кодировку UTF-8. По сути, это единственный интересный нюанс и еще какая-то настройка PostgreSQL для 1С 8.3 из-под Windows не потребуется. Установка и настройка PostgreSQL для 1С на ОС linux может вызвать ряд затруднений. Для их преодоления в качестве примера рассмотрим запуск работы (используя дистрибутивы ведущего российского вендора PostgreSQL-Pro и компании 1С) PostgreSQL на сервере Ubuntu 16.04 х64

    Установка дистрибутивов 1С для СУБД PostgreSQL

    1.Скачиваем указанную позицию дистрибутива СУБД PostgreSQL:

    2.Выкладываем PostgreSQL на сервер;

    3.Распаковать установщик СУБД PostgreSQL можно командой:

    4.Перед установкой дистрибутива СУБД PostgreSQL проверим наличие в системе необходимой локали (по умолчанию ru_RU.UTF-8):

    5.Если система, с которой будет работать PostgreSQL, ставилась с языком отличным от русского, необходимо создать новые локали:

    6.Если необходимая локаль все же имеется, устанавливаем ее по умолчанию:

    7.После перезагрузки, установим необходимые пакеты для нашей версии PostgreSQL:

    8.Версия PostgreSQL пакета 9.4.2-1.1C связана с пакетом libicu версии libicu48. В репозитории нужной версии уже нет, ее можно скачать;

    9.Скачиваем и помещаем в каталог, где хранятся скачанные файлы для PostgreSQL;

    10.Перейдя в каталог с файлами PostgreSQL, производим установку, последовательно набирая следующие команды:

    11.Готово. Дистрибутив СУБД PostgreSQL установлен.

    Установка дистрибутивов PostgreSQL-Pro

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

    Для доступа к серверу редактируем параметры в файле pg_hba.conf

    Сам файл имеет следующую структуру:

    Файл хорошо документирован, но на английском языке. Кратко рассмотрим основные параметры:

    TYPE

    • Local локальное подключение только через unix
    • Host подключение по TCP/IP
    • Hostssl шифрованное SSL-подключение по TCP/IP (сервер должен быть собран с поддержкой SSL, также требуется установить параметр ssl)
    • Hostnossl нешифрованное подключение по TCP/IP

    METHOD

    • trust допустить без аутентификации
    • reject отказать без аутентификации
    • password запрос пароля открытым текстом
    • md5 запрос пароля в виде MD5
    • ldap проверка имени и пароля с помощью сервера LDAP
    • radius проверка имени и пароля с помощью сервера RADIUS
    • pam проверка имени и пароля с помощью службы подключаемых модулей

    Более подробную и развернутую информацию можно посмотреть в документации к продукту PostgreSQL.

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

    После окончания основной установки, необходимо настроить конфигурационный файл сервера postgresql.conf, согласно специфики работы PostgreSQL, сервера 1С и конфигурации сервера Ubuntu.

    Оптимизация 1С под MS SQL Server

    Устанавливаем последние обновления для SQL Sever.

    Операционная система резервирует место и забивает его нулями, что занимает достаточно много времени при следующих событиях:

    • Создание базы данных;
    • Добавление файлов данных, журнал транзакций, к существующей базе данных;
    • Увеличение размера существующего файла (в том числе Autogrow-операций);
    • Восстанавливаем базы данных или группы файлов.

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

    При возможности необходимо разнести базу TempDB (особенно интенсивно она используется в режиме управляемых блокировок RCSI) и журнал транзакций на разные диски.

    На сервере, где работает SQL сервер, режим энергосбережения должен быть установлен в «Высокая производительность».

    По рекомендации Microsoft, разнести кластерные и некластерные индексы на разные диски, предварительно разместив некластерные индексы в отдельной файловой группе.


    В папке с файлами БД не должно быть сжатия.

    На вкладке «Память» для сервера устанавливаем минимальную планку в размере 50% от общего объема памяти. Максимальную рассчитываем по одной из формул:

    • Максимальная память = Общий объем – размер по ОС – размер под 1С (Если он есть, предварительно замерив счетчиками используемую память) или
    • Максимальная память = Общий объем – (1024* Общий объем/16384).

    Ограничиваем параметр DOP «Max degree of parallelism» и ставим его в значение «1».

    Актуализируем статистику по расписанию. Начиная с SQL Server 2008, обновление статистики вызывает перекомпиляцию запросов и, соответственно, очищает процедурный кэш, поэтому отдельную процедуру по очистке процедурного кэша выполнять не надо.

    Периодически проводим реиндексацию таблицы и дефрагментацию индексов.

    Устанавливаем правильную политику резервирования. Если вам не надо восстанавливаться на последний момент времени к краху системы, а последние минут 5 или больше для вашего бизнеса не критичны, то установите модель восстановления в «Простая». Этим вы ускорите в разы скорость при записи. Главное, чтобы дифференцированный бекап успевал выполняться за указанное время.

    Добиваемся улучшения при работе с TempDB при вводе/выводе посредством создания дополнительных файлов данных. Если логических процессоров меньше 8, рекомендуется создать файл данных для каждого логического процессора. Если логических процессоров больше 8, рекомендуется создать 8 файлов данных и, увеличивая на один при кратности 4, обязательно оценить нагрузку на TempDB.

    Мастер Йода рекомендует:  Свойство box-shadow

    Вложенные транзакции в postgresql 8.2?

    Я работаю над сценариями, которые применяют обновления схемы базы данных. Я настроил все мои сценарии обновления SQL, используя start transaction / commit. Я передаю эти скрипты в psql в командной строке.

    Теперь я должен применять несколько сценариев одновременно и в одной транзакции. Пока единственное решение, которое я придумал, – удалить начальную транзакцию / фиксацию из исходного набора сценариев, а затем объединить их в новый блок транзакции / фиксации начала. Я пишу perl-скрипты, чтобы сделать это на лету.

    Эффективно я хочу вложенные транзакции, которые я не могу понять, как это сделать в postgresql.

    Есть ли способ сделать или имитировать вложенные транзакции для этой цели? У меня есть настройки, которые автоматически срабатывают при любой ошибке, поэтому мне не нужно продолжать транзакцию верхнего уровня, если какой-либо из нижних не работает.

    У вас есть возможность использовать вложенные транзакции внутри postgresql с помощью SavePoints.

    Возьмите этот пример кода:

    Может быть, это поможет вам немного.

    Я закончил «решение» моей проблемы вне диапазона – я использую Perl-скрипт для повторной работы входных скриптов, чтобы устранить их вызовы транзакции / фиксации на запуск, а затем направить их все в один файл, который получает свою собственную транзакцию начала / совершить.

    Транзакции в Postgresql на C# при помощи Npgsql

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

    sConn и trans — глобально описанные подключение к БД и транзакция. При создании формы Select выполняется такой код:

    И вот, например, в первом приложении я выполняю такой код:

    Уровень изоляции — ReadUncommitted, то есть если я сейчас изменю в другой транзакции данные, то я увижу это изменение внутри выше описанной транзакции. Проверяем. В другом приложении выполняю такой код:

    Но! Нажав на кнопку «вывести баланс аккаунтов» из 1 приложения (1 транзакция), я получаю неизмененную информацию. Но ведь изоляция уровня ReadUncommitted. Как сделать так, чтобы 1 приложение увидело изменения?

    PostgreSQL 8.0: новые возможности

    PostgreSQL 8.0: новые возможности

    В середине января этого года вышла новая версия открытой системы управления базами данных PostgreSQL 8.0. Основные характеристики этой СУБД были рассмотрены ранее на страницах журнала (см. статью «PostgreSQL: первые шаги», №7, 2004 г.). По сравнению с 7-й веткой (на данный момент это версия 7.4.7) в 8-й версии появился ряд нововведений, краткому обзору которых и посвящена эта статья.

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

    Итак, добавлено понятие табличного пространства (table spaces). Раньше хранилище данных размещалось в директории, указанной при инициализации командой initdb, то есть жестко определялось на стадии инсталляции СУБД и могло находиться только на одной файловой системе. Проблемы со свободным местом приходилось решать либо с помощью переноса хранилища в другой раздел диска и размещения символьной ссылки на него, либо повторной инициализацией хранилища с последующим восстановлением данных из резервной копии. Теперь команда «CREATE TABLESPACE» позволяет создать несколько табличных пространств на разных файловых системах. И в дальнейшем при создании новой базы данных (CREATE DATABASE), таблицы (CREATE TABLE), индекса (CREATE INDEX) и т. д. можно указать, в каком табличном пространстве следует разместить объекты. Это помогает более гибко управлять размещением данных на диске и в ряде случаев повышает быстродействие, например, за счет выноса индексных файлов в табличное пространство, расположенное на отдельном жестком диске.

    Команда «ALTER TABLE» позволяет теперь изменять тип данных столбца. Раньше для этого требовалось создать новый столбец, перенести в него данные и затем старый удалить. До версии 7.3 удалять столбцы тоже было нельзя, и приходилось либо мириться с тем, что никому не нужный столбец занимает место, либо менять структуру таблицы самым универсальным способом – создавая на ее основе новую. Теперь для этого достаточно одной команды:

    ALTER TABLE test ALTER COLUMN mynum TYPE NUMERIC(4,2);

    Старый и новый типы должны быть совместимы. То есть вы можете изменить тип numeric(5,2) на numeric(9,2), чтобы хранить большие числа, но попытка изменить, например, числовой тип на строковый приведет к ошибке.

    Также в новой версии появились так называемые точки сохранения транзакций (savepoints). В ранних версиях в случае ошибки внутри транзакции она «откатывалась» полностью, что в сложных транзакциях (например, при отработке функций) приводило к значительной трате ресурсов. Теперь есть возможность в потенциально опасных местах транзакции размещать savepoints и в дальнейшем при обработке ошибки откатывать транзакцию только до указанной точки сохранения. Для этого используется команда «ROLLBACK TO savepointname», где savepointname – имя точки сохранения, присвоенное ей командой «SAVEPOINT savepointname». После устранения причины ошибки обработка транзакции продолжится, при этом операции, выполненные нормально, повторяться не будут.

    Команда «COPY», которая служит для загрузки данных в таблицу из внешних файлов и сохранения данных из таблиц в файлы, раньше поддерживала текстовый формат с разделителями и собственный двоичный формат. Теперь она поддерживает также работу с файлами в формате CSV (comma separated value), что упрощает обмен данными между PostgreSQL и, скажем, файлами Excel. Например, чтобы сохранить данные из CSV-файла, требуется подготовить таблицу, столбцы которой соответствуют по типу полям загружаемого файла. Затем выполняется команда:

    Максимальный размер транзакции в PostgreSQL

    У меня есть утилита в моем приложении, где мне нужно, чтобы выполнить массовую загрузку из INSERT IGNORE, UPDATE и DELETE операций. Я пытаюсь создать транзакцию вокруг этого так, что когда-то эта система вызова и данные подается к нему, обеспечивается то, что это либо все, либо никто не добавил в базу данных.

    Беспокойство, что есть, что граничные условия здесь? Сколько INSERT IGNORE, UPDATE и DELETE может я в одной транзакции? Является ли размер сделки настраивается?

    Любая помощь будет оценена.

    Одна транзакция может работать около двух миллиардов команд в нем (2 ^ 31, минус IIRC чуть-чуть над головой На самом деле, если подумать об этом, что может быть 2 ^ 32 -. Commandcounter беззнаковым я думаю).

    Каждая из этих команд может изменить несколько строк, конечно.

    Я не думаю, что есть максимальное количество работы, которая может быть выполнена в транзакции. Данные постоянно добавляться в файлы таблицы, и в конечном итоге сделка либо совершает или катится спины: AIUI этого результат сохраняется в pg_clog; если он выполняет откат, пространство в конечном счете, будет утилизирован в вакууме. Так что это не так, если текущая работа сделки проводятся в памяти и продувает во время фиксации, например.

    Для проекта я работаю, я выполняю 20 миллионов INSERT IGNORE. Я попробовал с одной крупной сделкой и с одной сделкой за каждый миллион ВСТАВКИ ИГНОРИРУЙТЕ и выступления кажется точно таким же.

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

    Я бы рекомендовал комков ваши обновления на управляемые куски, которые занимают большую пару минут времени исполнения, что, как вы знаете, если есть проблема раньше (например, то, что обычно занимает 1 минуту все еще работает через 10 минут . Ммм, сделал кто-то падение индекса?)

    Добавить комментарий
    Рубрика: Базы данных / Оптимизация