Базовая производительность DB2 COMMIT/ROLLBACK VS ROLLBACK TO SAVEPOINT

Question

В пакетной программе COBOL, что лучше в плане производительности?

Зафиксировать:

IF SW-NEW-TRANSACT 
    EXEC SQL 
     COMMIT 
    END-EXEC 
END-IF. 
PERFORM SOMETHING 
    THRU SOMETHING-EXIT. 
IF SW-ERROR 
    EXEC SQL 
     ROLLBACK 
    END-EXEC 
END-IF. 

С syncpoints:

IF SW-NEW-TRANSACT 
    EXEC SQL 
     SAVEPOINT NAMEPOINT ON ROLLBACK RETAIN CURSORS 
    END-EXEC 
END-IF. 
PERFORM SOMETHING 
    THRU SOMETHING-EXIT. 
IF SW-ERROR 
    EXEC SQL 
     ROLLBACK TO SAVEPOINT NAMEPOINT 
    END-EXEC 
END-IF. 

Answer 1

SAVEPOINT и COMMIT не являются взаимозаменяемыми.

Процесс должен в какой-то момент выполнять COMMIT или ROLLBACK работу базы данных. A COMMIT - - между транзакциями (между полными единицами работы). COMMIT может быть принято после каждой транзакции или, как это принято в пакетной обработке, после некоторого количества транзакций. A COMMIT должен никогда не принимать промежуточную транзакцию (это побеждает концепцию UNIT OF WORK).

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

Назначение SAVEPOINT - разрешить частичное резервирование изнутри единицы работы. Это полезно, когда процесс начинается с последовательности общих вставок/обновлений базы данных , за которыми следует ветвь процесса, где могут быть выполнены некоторые обновления, прежде чем можно будет определить, что ветка альтернативного процесса должна быть выполнена. SAVEPOINT позволяет отступить от ветви «тупика», а затем продолжить с дополнительной веткой , сохраняя при этом общую работу «впереди». Без SAVEPOINT поддержка «тупика» могла потребовать обширных данных, буферизующих транзакцию (сложную обработку) или ROLLBACK, и повторного выполнения с начала транзакции с каким-то флагом , указывающим, что альтернативный процесс необходимо следить за отраслью. Все это приводит к сложной логике приложения. ROLLBACK TO SAVEPOINT имеет ряд преимуществ. Он может сохранить работу «впереди», экономя затраты на ее выполнение. Это позволяет сэкономить всю транзакцию. Откат может быть больше «дорогим», чем исходные вставки/обновления, и может охватывать несколько транзакций (в зависимости от частоты фиксации). Наконец, сложность процесса обычно снижается, когда работа с базой данных может быть выборочно «отменена» через ROLLBACK TO SAVEPOINT.

Как можно использовать SAVEPOINT для повышения эффективности вашей пакетной программы? Если ваши транзакции используют самопроизвольные откаты для восстановления из обработки «тупика», то SAVEPOINT может быть огромным преимуществом. Точно так же, если внутренняя логика обработки усложняется , необходимо избегать выполнения обновлений баз данных для аналогичных требований «отвода», тогда SAVEPOINT можно использовать для рефакторинга процесса в , что довольно просто и, вероятно, более эффективно. Вне этих факторов SAVEPOINT не повлияет на производительность в положительном ключе.

Некоторые утверждают, что высокая частота COMMIT в пакетной программе снижает производительность. Следовательно, чем ниже частота фиксации , тем лучше производительность. Настройка частоты COMMIT не является тривиальной. Чем ниже частота фиксации, тем больше ресурсов базы данных составляет , и, следовательно, тем больше вероятность вызывать таймауты базы данных. Страдание таймаута базы данных обычно вызывает процесс отката. Откат - это очень дорогая операция . ROLLBACK - это большой успех для самой СУБД и вашей транзакции необходимо повторно применить все обновления во второй раз после ее перезапуска. Снижение частоты фиксации может привести к тому, что обойдется вам намного дороже, чем он получит. BEWARE!

EDIT

правило: Фиксирует имеют стоимость. Откат имеет более высокую стоимость.

Дисконтирование откаты из-за плохих данных, выход из строя устройства и программа завершается аварийно (все из которых должны быть редкими), большинство откаты вызваны тайм-аут из-за ресурсных разногласий между процессами. Выполнение меньшего количества коммитов увеличивает конкуренцию db. Выполнение меньшее количество коммитов может повысить производительность. Трюк заключается в том, чтобы найти, где производительность, полученная при невыполнении весом стоимости откатов из-за конкуренции. Там - это большое количество факторов, которые влияют на это - могут быть динамическими. Мой общий совет - искать в другом месте для повышения производительности - частота фиксации настройки (когда тайм-ауты не являются проблемой), как правило, является низкой доходностью инвестиций .

Другие более плодотворные пути совершенствования партии Палатки часто включают в себя:

• улучшение paralleslism нагрузкой расщеплению и запуск нескольких изображений одного и того же задания
• анализ DB/2 планы связывания и optomizing пути доступа
• профилирование поведения пакетных программ и реорганизация тех частей, которые потребляют наибольшее количество ресурсов

Answer 2

Это не проблема производительности на всех.

Вы COMMIT, когда вы заканчиваете единицу работы, независимо от единицы работы, означает ваше приложение. Обычно это означает, что вы обработали полную транзакцию. В пакетном мире вы берете фиксацию после 1000-2000 транзакций, так что вы не тратите все свое время COMMITING. Количество зависит от количества транзакций, которые вы можете повторить в случае ROLLBACK.

Вы ROLLBACK, когда вы столкнулись с какой-либо ошибкой, либо с ошибкой базы данных, либо с ошибкой приложения.

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