gardenman) а можно мне тоже на "это" посмотреть. исходники не надо. Просто хочу в гриде увидеть и побагать по табличке с миллионом записей.
Не выйдет ;-), оно всё на клиента тащит.

MDC разбивает таблицу на сегменты. Разница с Ораклячьим партишионированием в количестве партишенов/сегментов и заданием условий. Скажем, мы можем сделать MDC по измерениям X и Y, и сегментов будет столько, сколько разных пар (X,Y). Партишионирование в стиле Oracle требует прописывания в стиле "когда (X,Y) меньше чего-то-там, клади в такую-то партишен" или же вычислять хеш от (X,Y).

Если не менять определение таблицы, у DB2 для MDC количество партишенов зависит от данных, для Oracle у партишионированной количество партишенов таблицы постоянно.

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

На "прочих" серверах такое решают хинтами, а на Oracle ещё можно заставить "чужую" (т.е. без исходников) программу "придерживаться плана" при помощи stored outlines. Другое дело, я привык обходиться без хинтов, пусть оптимизатор сам решает. Да и не могу/не хочу я вмешиваться в то, что там GLORP нагенерил.

Схема базы данных - это проекция объектной модели, как фотография - проекция трёхмерного мира.

Я стараюсь концентрироваться на первичным и поменьше озабочиваться вторичным. Скажем, чего мне ковыряться в индексах - на это Index Adviser есть. Да, к сожалению, иногда приходится и MQT пользоваться, и об использовании MDC вопрос решать. Но время, потраченное на оптимизацию - это время, отнятое от более важных дел.

2 Anton Demidov:

Про DB2 на AS/400 и мэйнфреймах я не имею понятия - круто это или нет.

Накладные расходы, которые я имел в виду - это, во-первых, поддержание rollback segment'а, и во-вторых - записывание сведений блокировок прямо в страницы данных (лично я предпочитаю отдельный список и эскалацию блокировок). (Впервые слышу про эскалацию на табличное пространство). Это огромные и неустранимые расходы.

Напомню, что в журнале транзакций DB2 записываются данные для наката и отката. В Oracle данные для отката идут в rollback segment, но в redo log попадают все данные для наката, в том числе и наката rollback segment. Получается, что откат записывается по два раза.

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

Кстати, в ряде применений и режим грязного чтения (не путайте с фактом грязного чтения) совершенно нормален и корректен.

Про SQL почитайте кулинарную книжку. http://ourworld.compuserve.com/homepages/Graeme_Birchall/HTM_COOK.HTM.

Онлайн-бекап был ещё в 7-й версии Oracle, в 8-й появился rman, инкрементальный бекап и т.п., в 9-й появились, так сказать, более короткие команды rman'а. Но, чтобы пользоваться однокомандной командой rman'а, надо понимать, что за ней стоит. Необходимо знать огромное количество подробностей, о которых я не забочусь, используя DB2. Это очень и очень сложная штука. Для сравнения - бекап у DB2 по сложности примерно равен imp/exp в Oracle, что на порядок проще, при этом всякие online, incremental штучки и уменьшение нагрузки на базу имеются.

Я полагаю, Oracle тоже больше любит Rollback, чем Commit. Да, Flashback - это очень удобно и круто... когда в нём возникает нужда.

Полагаю, те динамические планы IBM, о которых говорил инструктор, это совсем не то, про что вы подумали. Dynamic SQL был "всегда". Но речь-то шла о подправке плана прямо во время выполнения запроса. Кодовое имя LEO optimizer (обучающийся оптимизатор). Никогда не слышал, чтобы у кого-то такое было.

Про "DB2 и MS SQL Server любят фиксированную длину строк. Oracle оптимизирован для переменной" - прошу привести доказательства либо ссылку на источник.

"однокомандная команда" -> "однострочная команда"

Anton Demidov[quot gardenman]на AS/400 VARCHAR столбцы хранятся в сегменте отдельном от столбцов фиксированной длины. Справедливо для 5R3. Как вывод - требуется дополнительная i/o операция.
Вы же говорили, что интерес представляет только DB2 for LUW, но не для AS/400. А потом сказали, что Oracle больше оптимзирован под VARCHAR, чем DB2 и MS SQL. Почему?