"ORACLE запоминает текущий SCN (системный номер изменения) как только запрос начинает выполняться." Разве SCN генерится не только в случае изменения данных, а ещё и при обычном селекте?
Posted 20 мая 2008 г.
Я, конечно, извиняюсь за назойливость, но непонятные моменты хочется прояснять. Что имелось ввиду под фразой "какой-то транзакцией"? Допустим, из внешней среды вызывается функция, которая только выполняет селект и возвращает данные. По какому SCN-у она будет выбирать данные, откуда она его возьмёт?
Posted 21 мая 2008 г.
Спасибо! Вроде бы ясно. То есть, перед выполнением запроса берётся последний сформированный SCN (то есть, по последней завершённой транзакции), относительно которого выбираются данные. Интересно было бы узнать про разновидности SCN-ов..
Posted 22 мая 2008 г.
Извиняюсь, попробую ответить, так как сам в своё время вникал в разницу. Если прочитать внимательно, то, собственно, у автора всё, что нужно, написано. А конкретно - дело в том, что речь идёт о данных по отношению к запросу. В первом случае при чтении фантомов (Р3), условиям запроса удовлетворяет больше данных. Во втором же случае (Р2) речь идёт об изменённых данных, которые были выбраны в первом запросе, но не попали вследствие их изменения или удаления в выборку второго запроса. На первый взгляд кажется, что разницы никакой, но всё-таки имеется принципиальная разница в теоретическом плане, при попытках всеобъять, так сказать. Поскольку в разных СУБД различна реализация согласованности данных и транзакционного процесса, это влечёт за собой особенности работы с данными в каждой конкретной СУБД, и возможно, что в пользу масштабируемости, им приходится жертвовать получением достоверных данных вместе с получением описанных "побочных" явлений. А иначе зачем, кроме как не по причине ограниченности ресурсов, всё это было придумано? Надо сказать, что оракловый транзакционный процесс не позволяет (не допускает - как угодно) полного соответствия явлений при выборке данных представленной "модели" явлений ANSI.
Posted 17 июня 2008 г.
Большое спасибо за внимание к моим вопросам! Обязательно почитаю.
Posted 8 мая 2008 г.
У меня снова возникли вопросы к статье: 1) Что из себя представляет массив изменений в векторе изменений? Его заголовок описан, пример приведен, все ясно. Массив длин изменений тоже вроде как понятно - "длина изменений" (хотя, что это такое - остается неясным), а вот "массив изменений" - темная лошадка. Рисунок, честно говоря, ничего не проясняет. 2) Далее: redo-запись состоит из своего заголовка и одного или нескольких векторов изменений. Вроде как понятно, что в поле RBA заголовка redo-записи есть участок "Byte number within block", который отвечает за номер измененного байта в блоке данных. Если я неправильно понимаю, поправьте. А что, если redo-запись содержит несколько векторов изменений, как тогда указывается номер байта в блоке данных? Простым перечислением? 3) Последний рисунок вообще не пояснен. Что означает UNDO и UNDO Header, совершенно непонятно - это redo-информация сегментов отката? Нельзя ли поподробнее про Slot. А также получается, что в redo-журналах хранится избыточная информация (в пользу надежности системы), ведь undo в нем нужны на случай сбоя системы, а потом лежат мертвым грузом? Так как в случае наката от какого-то состояния БД в прошлом будут использована только redo-информация? P.S.: кстати, рисунки большие и некрасивые в отличие от появившихся рисунков к статье "Формат блока в ORACLE".
Posted 7 мая 2008 г.
Спасибо за ответы. Начну сразу с третьего вопроса: статью я читал, но в ней нигде явно не написано, что состояние БД можно восстановить на любой момент времени. Правда, как я понимаю, восстановление возможно начиная с момента, на который снят дамп БД путем наката по данным redo-журналов. Все ясно. По поводу первого вопроса. Вот что я смог получить: REDO RECORD - Thread:1 RBA: 0x021c18.00000003.00f0 LEN: 0x003c VLD: 0x01 SCN: 0x000a.7a9897ef SUBSCN: 1 05/12/2008 15:16:48 CHANGE #1 TYP:0 CLS: 1 AFN:74 DBA:0x1299d873 SCN:0x000a.6ef39438 SEQ: 1 OP:4.1 Block cleanout record, scn: 0x000a.7a9897ef ver: 0x01 opt: 0x01, entries follow... itli: 1 flg: 1 scn: 0x000a.790aa931 Здесь первые две строки - это заголовок redo-записи, далее идет заголовок вектора изменения. А вот что такое "Block cleanout record, scn: 0x000a.7a9897ef ver: 0x01 opt: 0x01, entries follow... itli: 1 flg: 1 scn: 0x000a.790aa931 " - непонятно..
Posted 12 мая 2008 г.
Да, стало понятно, спасибо.
Posted 14 мая 2008 г.
И что Вы предприняли в этой ситуации? Интересно было бы узнать..
Posted 24 июня 2008 г.
Непонятно только, какими данными вы её заполнили после создания? Или это не важно?
Заметка касается только блоков данных? А как обстоит дело с блоками данных, в которых находятся индексы? Или я что-то пропустил?
Я имел ввиду, зависит ли распределение блока данных между списками от его типа (табличный, индексный, кластерный)? Или они попадают как получится, вперемешку и всё зависит от вычисленного хэш-значения?
Posted 25 июня 2008 г.
Понятно. Oracle не делает разницы между типами блоков данных. Табличный, индексный и кластерный блоки данных размещаются в зависимости только от их file# и block#. Спасибо.
Всё-таки, при дальнейшем изучении документации было обнаружено предложение о том, что подсказки кроме RULE включают CBO (та же Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2), Chapter 5, Optimizer Hints): "Hints (except for the RULE hint) invoke the cost-based optimizer (CBO). If you have not gathered statistics, then defaults are used.". То есть, если тщательно искать и обязательно в разных местах, то найдёшь ответы на многие вопросы!
Posted 24 июля 2008 г.
Блог веб-разработчиков
О налогах в Украине
Про податки в Україні
Записки для начинающих о СУБД Oracle