Exadata Storage Server, part 2

Exadata Storage Server, part 1 .

Наверное, самое интересное техническим специалистам, а как именно происходит фильтрация данных, как именно Exadata возвращает меньше данных, чем обычный дисковый массив ?

В английской терминологии этот процесс еще называют Predicate Offload или Smart Scan.

Оптимизатор может использовать режим обращения Predicate Offload только, если запрос использует Direct Read Full table scan и таблица расположена на дисковой группе, которая состоит из дисков Exadata. Обычно, Direct Read производиться, используя Parallel Query. В Parallel Query один процесс выполняет роль координатора, другие (PQ slaves) выполняют собственно чтение. PQ slave, определяет фильтр и набор за писей, который ему нужно прочитать. Если это возможно, вместо кода чтения direct path вызывается код взаимодействия с Exadata (речь идет о kernel code path). Этот код, с помощью ASM, переводит имена сегментов в диски, смещения, необходимый объем для чтения. Дальше открывается специальный поток, в котором эти данные передаются на Exadata. (если у нас несколько cell, это также легко определить с помощью метаданных ASM. Таким образом правильный набор команд посылается нужному cell)

Процесс CELLSRV на стороне Exadata, получает поток команд на чтение и необходимый фильтр. Далее с помощью библиотеки из состава ядра Oracle он выполняет необходимую фильтрацию и возвращает результат. Результат - это только необходимые нам записи и колонки. Я где-то прочитал, что на самом деле это блоки БД, которые содержат только нужные данные, но не подтвердить, не опровегнуть этого утверждения не могу.

На самом деле, процесс конечно более сложный, там целый протокол общения - iDB (Intelligent Database protocol). Из документов следует, что iDB работает через Reliable Datagram Sockets (RDSv3), не могу не процитировать "extremely fast low-latency protocol".

Что следует из вышеприведенного текста. Ячейкам Exadata (cell) нет необходимости общаться между собой в момент выполнения запроса. Каждая ячейка получает нужную ей команду.

Поскольку речь идет о Direct Path Read, нет проблемы c read consistency. Перед началом Direct Path Read всегда выполняется tablespace checkpoint object-checkpoint, т.е. сброс грязных блоков этого объекта.

Выполнение Join. Exadata не выполняет Join. Их по прежнему выполняет сервер СУБД. Но если идет связка очень большой и очень маленькой таблицы, почему бы не подсказать Exadata некоторые ключи для фильтрации ? :)

Презентация с OpenWorld утверждает, что Smart Scan умеет обрабатывать:

• Uncommitted data and locked rows
• Chained rows
• Compressed tables
• National Language Processing
• Date arithmetic
• Regular expression searches
• Partitioned tables

А также:

• Star join filtering is performed within Exadata storage cells
• Dimension table predicates are transformed into filters that are applied to scan of fact table

Последнее утверждение совпадает с тем, что я написал чуть выше про Join.

Наконец еще несколько деталей. Я приводил график, из которого следует, что сильно ускоряется например tablespace creation. Можно предположить, что с сервера СУБД просто идет команда Exadata на разметку определенного дискового пространтсва, что конечно быстрее чем форматировать каждый блок .

Конечно, у Вас могут одновременно существовать дисковые группы ASM и на обычном массиве и на Exadata. Ограничение - в составе одной группы могут быть только диски одного типа (либо Exadata grid disk, либо обычнные). Но я пока не знаю, можно ли выполнять smart scan по таблице, чьи партиции лежат на разного типа группах ? Подозреваю, что нет.


Продолжение следует... Поговорим о миграции и стоимости. А пока, расскажите об этом блоге своему директору :))))))