Очень частая фиксация транзакций - без этого никак?

[avzh]

Здравствуйте. У нас в организации работает Аксапта на Оракле. Наблюдая за БД я наблюдаю очень большое время ожиданий сессий для события log file sync. (Для непосвященных, это событие происходит, когда сессия фиксирует транзакцию и ждет когда на диск будут сброшены из памяти данные повторного выполнения) При этом для некоторых не очень долгих процедур я наблюдаю огромное число для статистики user commits (несколько тысяч). Я понимаю необходимость частой фиксации транзакций в MS SQL, но в Oracle это только лишняя операция, потребляющая ресурсы (очень небольшие, но когда несколько сессий да по несколько тысяч...). Как пишут классики, "фиксировать транзакцию нужно только когда это НУЖНО". Вопрос: можно ли в коде Аксапты это править или это "зашито" в ядре? Спрашиваю для того, чтобы знать можно ли на это указать программистам, или это не в их компетенции?
Заранее благодарю всех ответивших.

[komar]

TTSBegin--TTS Commit в коде. Только стоит ли? Лучше оставьте железяку в покое....

[avzh]

См. тему сообщения.

[George Nordic]

Наш многоуважаемый администратор (usp) выразил сомнение, что База, log file, temp и undo находяться у Вас на разных дисках.
Можете конфигурацию поподробнее?

[avzh]

Да железо здесь ни при чем, то есть конечно, если логи на медленных дисках, то это будет притормаживать на сбросе log buffer'ов, но основная причина в огромном количестве commit'ов. То есть буквально открывается цикл, в нем производится update и сразу commit. Так несколько тысяч раз. Мой вопрос не в том, как сконфигурить сервер, а можно ли управлять транзакциями БД в коде Аксапты, или она это делает сама?

[George Nordic]

В своем коде - можно. Но там уже написаны сотни тысяч строк кода. Не прикажете ли выковыривать оттуда ttsbegin ttscommit? К тому же, как можно писать код без транзакций??? Вы понимаете, к чему это может привести? Хотя транзакции внутри цикла - мови тон... нельзя было хотя бы за цикл вынести? Это не походе на аксаптовский код. Пытайте программеров.

С Уважением,
Георгий

[komar]

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

[Глазков]

Это надо в Оракле рыться. Я похожую СУБДу администрировал (Progress) там было много разных настроек - типа длина кластера undo-log, отложенная запись и еще, и еще... На оракле пишутся, в том числе, и "очень транзакционные" БД - и ничего, существуют, дышат и даже летают нет-нет.

Резюме: программеров трогать скорее всего бессмысленно, а вот Ораклу надо помочь

[iggl2]

Цитата:

Изначально опубликовано George Nordic
В своем коде - можно. Но там уже написаны сотни тысяч строк кода. Не прикажете ли выковыривать оттуда ttsbegin ttscommit? К тому же, как можно писать код без транзакций??? Вы понимаете, к чему это может привести? Хотя транзакции внутри цикла - мови тон... нельзя было хотя бы за цикл вынести? Это не походе на аксаптовский код. Пытайте программеров.

С Уважением,
Георгий

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

[usp]

Уважаемый avzh прав в том, что начал с поисков в коде: "умелым" программированием можно поставить на колени любой сервер.
Георгий также говорит дело - не стоит давать commit при каждой итерации цикла (за исключением очень специфических случаев). И, если без такого решения не обойтись, то и сервер необходимо настроить определённым образом - для поддержки очень частых и коротких транзакций.
А вот iggl2 я попросил бы ВЕЖЛИВО развить свою мысль относительно длинных транзакций. Я так понимаю, что это принципиальный подход к Аксапте? Чем же обусловлен такой однозначный выбор?

[Андре]

Цитата:

Я так понимаю, что это принципиальный подход к Аксапте? Чем же обусловлен такой однозначный выбор?

Хм... Concurrency control и сопутствующие ему блокировки - задача сервера СУБД, а ни как не его клиента.
Другое дело, что в Oracle и MS SQL очень по-разному решены эти задачи.
Так например в MS SQL есть Lock Manager, который отвечает за все блокировки. При каждом обращении к БД lock manager выдает информацию - свободен ли ресурс. Поэтому в MS SQL блокировки - дорогостоящий ресурс. Поэтому в MS SQL и существует такая вещь, как эскалация блокировок.
В Oracle информация о блокировке хранится в самом блоке данных, точнее в его заголовке и никаких дополнительных ресурсов на это хранение не тратится, что позволяет более "расточительно относиться к блокируемым ресурсам". И именно поэтому в Oracle нет надобности в эскалации блокировок.
Если вспомнить про версионность Oracle - то разница в подходах станет еще более значительной.

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

То есть, если по классике (читаем Кайта) для Оракла длинные транзакции не есть плохо и решение об длительности транзакции разработчик принимает только на основании того, сколько нужно для лочной функциональности, то в MS SQL длительные транзакции могут обернуться большими проблемами.