В связи с наличием анлимов на смартфоне в 2017 это уже не очень актуально, достаточно иметь удобный способ оплаты не только в домашней сети( без ввода стосимвольных айди абонента)
есть два типа полетов — визуальные и инструментальные. все боинги и проч большие летают только инструментально. в IFR нельзя доверять тому что видишь в окно, только приборам. а безопасные интервалы обеспечивают диспетчеры, диспетчерские системы управления и tcas
но самое опасное, принимать таких людей за подтверждение теории.
Я думаю, если посмотреть процент успешных людей занимающихся медитацией по технике Шаматха, процент успешных людей, сидящих на этих психотаблетках, и пр, то внезапно окажется, что он примерно тот же, что и процент этих людей в обществе, т.е. успех от этого всего не зависел.
еще пять копеек от коллег: flashback query никогда не учавствует в shared cursors, т.е. каждый селект с флэшбеком это и parse и flood в library cache. Т.е. для продакшена это вообще, никак-никак не рекомендуется в каком-то повторяющемся коде.
Oracle использует оптимистический подход к блокировкам, и ничего заранее не блокирует и никого не приостанавливает. Предположим такой вариант: сессия ставит себе isolation_level=serializable, а другая сессия после этого апдейтит какую-то строчку. Затем, наша serializable сессия пробует обновить эту строчку. Где-то в другой вселенной первый апдейт должен был быть заблокирован нашей сессией, но не в оракле, в оракле мы получим во втором апдейте ORA-08177: can't serialize access for this transaction. Таким образом наша транзакция никого не будет держать(ну кроме конкуренции за shared pool, т.к. нужно snapshot востанавливать для сессии и память на это тратить…
Если мы берем flashback query — то и там и там механизм один и тот же — UNDO, и там и там будет snapshot too old если данные из undo ушли. Расскажете, чем будет отличаться в этой самой OLTP нагрузке сессия которая по прочитанному SCN будет делать flashback query от serializable транзакции? Или, таки, ничем?
1) создается нагрузка на продакшн
2) flashback — часть функционала Enterprise Edition — другие деньги за лицензирование
3) DB_FLASHBACK_RETENTION_TARGET не дает 100% гарантии получения снэпшота за этот ретеншн.
Если стоит цель просто получить текущий консистентный набор данных, то всё гораздо проще, достаточно поставить SERIALIZABLE транзакционный уровень изоляции и просто выбрать данные.
А если стоит задача сделать постоянный процесс — почему не взять и сделать master-slave репликацию на сервер аналитики или на промежуточный сервер для ETL? Есть куча средств, начиная от ораклового GoldenGate до всяких SymmetricDS. В простейшем случае это вообще standby юнит, останавливаете применение логов = неизменяемый снепшот, выгрузили данные, поехали дальше апплаить… Этим может заниматься пассивный юнит, чтобы не простаивал, например.
В видео ситуация немножко другая, там идет обращение к элементу массива по инкрементируюмуся указателю, и если постинкремент позволяет сначала использовать смещение для доступа к памяти, а потом увеличивать указатель(пока dma работает), то сначала инкремент заставляет сначала ждать инкремент, а потом запускать фетч из памяти.
По идее, еще быстрее должно работать что-то типа *a++ =…
Но в реальной жизни, думаю, компилятор из всех вариантов сделает одно и то же.
В связи с наличием анлимов на смартфоне в 2017 это уже не очень актуально, достаточно иметь удобный способ оплаты не только в домашней сети( без ввода стосимвольных айди абонента)
сравнивать самолеты и авто вообще нельзя, поэтому
но самое опасное, принимать таких людей за подтверждение теории.
Я думаю, если посмотреть процент успешных людей занимающихся медитацией по технике Шаматха, процент успешных людей, сидящих на этих психотаблетках, и пр, то внезапно окажется, что он примерно тот же, что и процент этих людей в обществе, т.е. успех от этого всего не зависел.
SQL> select lo.session_id
2, lo.oracle_username locker
3, lo.os_user_name,o.owner||'.'||o.object_name object
4, o.object_type
5, decode(lo.locked_mode,
6 1, 'No Lock',
7 2, 'Row Share',
8 3, 'Row Exclusive',
9 4, 'Shared Table',
10 5, 'Shared Row Exclusive',
11 6, 'Exclusive') locked_mode
12 from v$locked_object lo, dba_objects o
13 where lo.object_id=o.object_id;
SESSION_ID LOCKER OS_USER_NAME OBJECT OBJECT_TYPE LOCKED_MODE
— — — — — —
SQL> alter session set isolation_level=serializable;
Session altered
SQL>
SQL> select lo.session_id
2, lo.oracle_username locker
3, lo.os_user_name,o.owner||'.'||o.object_name object
4, o.object_type
5, decode(lo.locked_mode,
6 1, 'No Lock',
7 2, 'Row Share',
8 3, 'Row Exclusive',
9 4, 'Shared Table',
10 5, 'Shared Row Exclusive',
11 6, 'Exclusive') locked_mode
12 from v$locked_object lo, dba_objects o
13 where lo.object_id=o.object_id;
SESSION_ID LOCKER OS_USER_NAME OBJECT OBJECT_TYPE LOCKED_MODE
— — — — — —
SQL>
Oracle использует оптимистический подход к блокировкам, и ничего заранее не блокирует и никого не приостанавливает. Предположим такой вариант: сессия ставит себе isolation_level=serializable, а другая сессия после этого апдейтит какую-то строчку. Затем, наша serializable сессия пробует обновить эту строчку. Где-то в другой вселенной первый апдейт должен был быть заблокирован нашей сессией, но не в оракле, в оракле мы получим во втором апдейте ORA-08177: can't serialize access for this transaction. Таким образом наша транзакция никого не будет держать(ну кроме конкуренции за shared pool, т.к. нужно snapshot востанавливать для сессии и память на это тратить…
1) создается нагрузка на продакшн
2) flashback — часть функционала Enterprise Edition — другие деньги за лицензирование
3) DB_FLASHBACK_RETENTION_TARGET не дает 100% гарантии получения снэпшота за этот ретеншн.
Если стоит цель просто получить текущий консистентный набор данных, то всё гораздо проще, достаточно поставить SERIALIZABLE транзакционный уровень изоляции и просто выбрать данные.
А если стоит задача сделать постоянный процесс — почему не взять и сделать master-slave репликацию на сервер аналитики или на промежуточный сервер для ETL? Есть куча средств, начиная от ораклового GoldenGate до всяких SymmetricDS. В простейшем случае это вообще standby юнит, останавливаете применение логов = неизменяемый снепшот, выгрузили данные, поехали дальше апплаить… Этим может заниматься пассивный юнит, чтобы не простаивал, например.
Про итераторы полностью согласен.
В целом, эта магия постфикса идет с этих типовых функций типа *strdest++ = *strsrc++, которые транслировались в movs, думаю так.
По идее, еще быстрее должно работать что-то типа *a++ =…
Но в реальной жизни, думаю, компилятор из всех вариантов сделает одно и то же.