Can this hurt Oracle?

[Palych]

Имеется некоторый процесс, который читает файлы (xml) с диска, парсит и вставляет в некую таблицу.
Работает на 6 серверах, на каждом - 2-4 потока.
Вопрос: если вдруг привалит работы всем этим процессам и они начнут вставлять не по детски (практически без пауз, поскольку чтение и парсинг быстрые) может ли это поставить Oracle на колени?
Так что остальные запросы встали?
Можно ли как-то сказать базе что эти вставки имеют низкий приоритет?
И нужно ли?
Понимаю что вопрос сумбурный, на всякий случай - вдруг есть какое-то всем известное решение проблемы. Или проблемы вовсе нет...

[iDesperado]

большой объем вставок redo лог может загрузить, так что другие встанут на ожиданиях переключения redo. ну и ио может отъесть у других, если раздел один на всех. приоритет можно выставить в EE редакции, можно тут почитать https://docs.oracle.com/cd/E11882_01/se ... ADMIN11841
я бы еще подумал на тему архиектуры, что бы пользовательские процессы добавляли только очередь, например в AQ, а обработкой очереди уже джобы в оракле занимались, кол-во которых можно было бы регулировать в зависимости от хотелок.

[Albert_al]

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

Прекрасная идея! :!:

[mynameiszb]

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

Наступал на подобную проблему лет 10 назад. Гнали огромный поток вставок с разных процессов и после каждой записи делали commit.
В итоге сервер начинал затыкаться. Сделали буферизацию - и все побежало.

[Palych]

А есть ли в современных базах возможность сказать: "вставь и тут же сделай commit", чтобы лишний раз не гонять пакеты?
Другими словами - знает ли Oracle когда jdbc connection is in auto commit mode?

[mynameiszb]

А есть ли в современных базах возможность сказать: "вставь и тут же сделай commit", чтобы лишний раз не гонять пакеты?
Другими словами - знает ли Oracle когда jdbc connection is in auto commit mode?

Ораклу без разницы, что именно хочет заказчик. Оракл - не предсказатель. И мне кажется, это относится и к другим базам. Сказал клиент commit - значит ему (клиенту) это позарез надо. Выполняем.

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

[Palych]

Ораклу без разницы, что именно хочет заказчик. Оракл - не предсказатель. И мне кажется, это относится и к другим базам. Сказал клиент commit - значит ему (клиенту) это позарез надо. Выполняем.

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

Мне этот случай не кажется странным.
Мне нужно вставить запись. Как только операция завершилась - я хочу быть уверенным что база её не потеряет.
Что я могу ещё сказать?
Почему я сначала должен сказать "вставь", а потом - "сделай так, чтобы то что я вставил не потерялось"?
Кстати, в случае с очередями внутри Oracle - клиенту тоже нужно два раза бегать?

[Palych]

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

Те файлы и есть очередь. И количество хотелок можно регулировать.
Правда не меньше одной на сервер, но сути это не меняет.
Фундаметнальный вопрос в том сколько хотелок могут в принципе положить базу если между insert/commit практически не будет промежутка?

[iDesperado]

Мне этот случай не кажется странным.
Мне нужно вставить запись. Как только операция завершилась - я хочу быть уверенным что база её не потеряет.
Что я могу ещё сказать?

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

[Easbayguy]

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

Те файлы и есть очередь. И количество хотелок можно регулировать.
Правда не меньше одной на сервер, но сути это не меняет.
Фундаметнальный вопрос в том сколько хотелок могут в принципе положить базу если между insert/commit практически не будет промежутка?

Это смотря какая бабель!

[mskmel]

Работает на 6 серверах, на каждом - 2-4 потока.
Вопрос: если вдруг привалит работы всем этим процессам и они начнут вставлять не по детски (практически без пауз, поскольку чтение и парсинг быстрые) может ли это поставить Oracle на колени?

Если сервер и СХД выпущены за последние 5 лет, то 2-4 потока не смогут скорее всего. Разве что место закончится где-нить, но это скорее не 2-4 потока виноваты, а мониторинг.

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

Проще:
You can control the maximum number of concurrently active sessions allowed within a consumer group. This maximum defines the active session pool. An active session is a session that is in a call. It is considered active even if it is blocked, for example waiting for an I/O request to complete. When the active session pool is full, a session that is trying to process a call is placed into a queue. When an active session completes, the first session in the queue can then be removed from the queue and scheduled for execution. You can also specify a period after which a session in the execution queue times out, causing the call to terminate with an error.

А есть ли в современных базах возможность сказать: "вставь и тут же сделай commit", чтобы лишний раз не гонять пакеты?
Другими словами - знает ли Oracle когда jdbc connection is in auto commit mode?

Ключевое слово "auto-commit mode".
http://docs.oracle.com/javase/tutorial/ ... tions.html

[Palych]

знает ли Oracle когда jdbc connection is in auto commit mode?

Ключевое слово "auto-commit mode".
http://docs.oracle.com/javase/tutorial/ ... tions.html

Я извиняюсь, но не могли бы Вы показать где там ответ на мой вопрос?

When a connection is created, it is in auto-commit mode. This means that each individual SQL statement is treated as a transaction and is automatically committed right after it is executed. (To be more precise, the default is for a SQL statement to be committed when it is completed, not when it is executed. A statement is completed when all of its result sets and update counts have been retrieved. In almost all cases, however, a statement is completed, and therefore committed, right after it is executed.)

Чисто теоретически это можно сделать двумя путями:
1. Драйвер делает commit в конце statement.execute...
2. База данных знает (через параметры сессии или запроса) что запрос должен быть закоммичен сразу после выполнения.

Реализует ли кто-нибудь второй вариант?

[mynameiszb]

Чисто теоретически это можно сделать двумя путями:
1. Драйвер делает commit в конце statement.execute...
2. База данных знает (через параметры сессии или запроса) что запрос должен быть закоммичен сразу после выполнения.

Реализует ли кто-нибудь второй вариант?

Что-то я ваш вопрос не совсем понимаю.

Любое обращение к базе данных настраивается. Настроек, фактически по комитам, две: auto-commit после любого обращения к базе и manual-commit, когда вы посылаете внятно команду после набора действий.

В случае DDL операций на вашем соединении с базой обычно происходит скрытый Commit, что иногда народ ставит в тупик - "я же явно не говорил этого делать!"

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

[Palych]

Любое обращение к базе данных настраивается. Настроек, фактически по комитам, две: auto-commit после любого обращения к базе и manual-commit, когда вы посылаете внятно команду после набора действий.

Я не про настройки, а про реализацию, абстрактно.
Допустим нужно мне вставить запись. Делаю это в двух вариантах:
1.

Code: Select all

con.setAutoCommit(true);
con.prepareStatement(...).executeUpdate();

2.

Code: Select all

con.setAutoCommit(false);
con.prepareStatement(...).executeUpdate();
con.commit();

Будут ли эти способы отличаться с точки зрения сервера БД?

[mskmel]

1. Драйвер делает commit в конце statement.execute...

Это ^^^^^^^^^

sqlplus, VBA, jdbc, etc - это их настройка дёргать commit после завершения каждой операции.
Не делайте из мухи слона, за последние лет 10 там такое нагородили вокруг чекпоинтов, что 100500 каммитов, если смогут, от всего-то 2-4х сессий, погоды не сделают. Для успокоения души или прикрытия попы в тестовой базе проведите мини-нагрузочное тестирование.

[Palych]

1. Драйвер делает commit в конце statement.execute...

Это ^^^^^^^^^

sqlplus, VBA, jdbc, etc - это их настройка дёргать commit после завершения каждой операции.

Спасибо!
Для протокола отмечу что данный вопрос строго говоря является оффтопиком.
Извиняюсь за запутывание уважаемой публики.
Я просто подумал что такая фича (указание базе чтобы коммитила сразу после выполнения) позволила бы ускорить некоторые, возможно многие операции.

Не делайте из мухи слона, за последние лет 10 там такое нагородили вокруг чекпоинтов, что 100500 каммитов, если смогут, от всего-то 2-4х сессий, погоды не сделают. Для успокоения души или прикрытия попы в тестовой базе проведите мини-нагрузочное тестирование.

Ещё раз благодарю!
Я тут прикинул и решил что будет проще добавить небольшой тормозок в систему чем доказывать что всё будет хорошо: некоторые коллеги решили упереться рогом в стенку. Кто знает - может они и правы. Моё дело телячье: обвалялся - и стой...

[Palych]

Имхо проблемы нет. По 4-5 тысяч маленьких хмл фаилов в сутки с парсингом на сервере БД. Общий обьем где около 40 гб. Но если у вас терабайты, то я не знаю.

Парсинг как раз на сервере приложений. Объёмы по-моему примерно такие, даже меньше скорее всего.

[Palych]

"Я просто подумал что такая фича (указание базе чтобы коммитила сразу после выполнения) позволила бы ускорить некоторые, возможно многие операции."

На самом деле с точностью до наооборот. Слишком частый commit заставляет Oracle делать запись в redo-log file слишком часто.

Мне казалось что зная заранее намерение клиента, база может склалывать эти сообщения в очередь (persistent queue) и выполнять пачками...
Хотя наверное я куйню сковал: пользователь же будет ожидать что запись будет доступна сразу по окончанию execute()
В общем - never mind...

[mskmel]

Имхо проблемы нет. По 4-5 тысяч маленьких хмл фаилов в сутки с парсингом на сервере БД. Общий обьем где около 40 гб. Но если у вас терабайты, то я не знаю.

... Объёмы по-моему примерно такие, даже меньше скорее всего.

Забить до тех пор, пока сервер БД не перейдет на виртулку на лэптопе и дневной объем увеличится хотя бы раз в 10

[Palych]

"Я просто подумал что такая фича (указание базе чтобы коммитила сразу после выполнения) позволила бы ускорить некоторые, возможно многие операции."

На самом деле с точностью до наооборот. Слишком частый commit заставляет Oracle делать запись в redo-log file слишком часто.

Мне казалось что зная заранее намерение клиента, база может склалывать эти сообщения в очередь (persistent queue) и выполнять пачками...

Я кажется понял о чём я говорил: Lazy/Asynchronous Commit, delayed durability...

[baton]

Bulk load практически не генерит логов, поетому в етой ситуации скорее ляжет ваша сеть чем Оракл