Почитал ньюфичез PL/SQL Developer'a 10

И вычитал для себя пару мастхавных:



И пару весьма приятственных:




Надо апаться 

Это сообщение отредактировал(а) Zloxa - 15.3.2013, 10:06

Так это вроде запрещено самим Ораклом, нет?

Фигзна - в это я не вникал  

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

НО фича - мастхав - факт 


Это сообщение отредактировал(а) Zloxa - 18.3.2013, 10:52

Вот статейка где объясняется почему результаты DBMS_OUTPUT не видны до конца работы PL/SQL.

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

dbms_sql умоминается только в этом контексте


Здесь скорее о следствиях нежели о причинах.


DBMS_OUTPUT сохраняет информацию в output буфере, который находится в контексте сессии. В один момент времени, сессия может либо выполнять клиентский  запрос(под запросом имеется в виду запрос с клиента - будь то фетч, будь то выпонение запроса, будь то выполнение pl/sql блока). Либо ждать когда этот клиентский запрос поступит. Т.о. До тех пор, пока PL/SQL блок выполняется, контекст сессии оказывается не доступен для чтения, т.к. сессия не доступна для клиентских запросов. Но в случае остановки по брикпойнту...

В пакете dbms_debug есть процедура execute, которая позволяет выполнить операцию в контексте отлаживаемой сессии, если та находится в режиме ожидания. В двеятошной версии ее спецификация на первый взгляд не отличается от одинатошной. Соответственно, нет, наверное , ничего военного в том, чтобы оформить dmbs_output.get_line из отладочной сессии, запустить его в отлаживаемой и получить биндом результат в отладночной.

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

Это сообщение отредактировал(а) Zloxa - 18.3.2013, 14:43

Возможно и так, тогда еще один минус в карму Оракла 

Глубина этой мысли мне не понятна.
Не понятно даже о чем эта мысль и причем здесь оракл.


Какие - то другие клиент-серверные системы позволяют опрашивать сессию в тот момент, когда она занята и не ждет запросов? 

Это сообщение отредактировал(а) Zloxa - 18.3.2013, 16:08

Это к вопросу о том соблюдении ACID.

Спорный вопрос. Лэйзи коммиты благо в куда большем числе кейсов. А когда дейсвтительно нужны суровые коммиты, их никто вроде как не запрещает.

Минус в кармну не засчитнан.

Ты пропустил одно важное дополнение, неявные. Там вся фишка в том, что для PL/SQL ленивые комиты включаются неявно: отдельный параметр и включены по умолчанию.
Если уж ленивый комит такое бобро в большем числе кейсов, почему умолчальное поведение для обычного SQL это WAIT?

Могу лишь предполагать, что, возможно, потому, что вероятность того, что внешнее приложение использует для коммуникации нетранзакционные средства - куда выше.

Не понял, как это связано с поведением Оракла?

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

К сожалению я не нашел сейчас в документации, но много раз встречал ранее в других источниках, что сброс на диск зафиксированных в pl/sql транзакций производится при возврате управления из PL/SQL. Автор статьи это вроде как подтверждает экспериментально.

Т.о. пусть ты выполняешь процедуру



Итак, после того как нас рубануло, мы будем иметь в базе записи 1 и 2.
Клиентское приложение не информировано об успешном завершении работы процедуры, при восстановлении работоспособности, процедура должна будет быть вызвана повторно.
Транзакции, успевшие увидеть записи 3 и 4, так же не сбросились на диск и были не восстановлены, можно сказазать что их никогда и не было.

В чем разница, рубануло бы нас на вставке значения 3 или рубануло нас после ленивого коммита значения 4?



Это сообщение отредактировал(а) Zloxa - 19.3.2013, 13:16

Придумал кейс.
Эти записи могла успеть считать какая-то другая система и успеть на их основании принять и сохранить решение в не подконтрольном транзакционной системе оракла контексте.

Кейс несколько высосан из пальца, мне думается, но всяко может хаппенс. Но выглядит этот кейс все-же скорее весьма и весьма исключительным, в таких случаях, действительно определенно нужен write immediate wait;

Это сообщение отредактировал(а) Zloxa - 19.3.2013, 13:49

Именно.