Комментарии прочитаны и приняты.
...но, к сожалению, не осознаны
Order by rowid вполне подходит
rowid, если уж Вы рассмотрели его структуру, суть указатель на
физическое размещение строки.
Одно это должно было заставить Вас заподозрить подвох.
Дальше неплохо бы знать пару кое-что про выделение места в табличных пространствах oracle rdbms, но для этого - увы и ах - надо было читать документацию.
Есть как минимум три вещи, не позволяющие считать rowid монотонно возрастающим, и которые Вы никогда не сможете осознать на базе эспериментов над парой тысяч строк:
1. Обычное (не bigfile) табличное пространство может состоять (и обычно состоит) из нескольких файлов данных, заполняемых +-равномерно.
В этом месте отсылаю к той самой структуре rowid, а именно - к компоненте "номер файла данных".
2. Место под хранение в табличном пространстве выделяется экстентами. Механизмов выделения экстентов исторически есть несколько штук, но в контексте обсуждаемого вопроса следует знать, что любой из них предпочтет расширению табличного пространства выделить место там, где оно есть по факту.
Тут снова отсылаю к структуре rowid, компонент - номер блока.
3. Если вставка осуществляется conventional insert (т.е. без применения механизмов direct/append), то механика oracle предпочтет вставить новые строки в те блоки, которые значатся у него как свободные (т.е. не забитые под завязку). Этих механизмов тоже исторически есть несколько штук, но все они также работают на более плотную упаковку данных. Компоненты "Номер файла", "номер блока".
Таким образом, даже без учета административных воздействий на БД полагаться на монотонность rowid суть большая глупость.
этот порядок уже и так является по умолчанию для индексных запросов.
Не очень понятно что такое "индексный запрос".
Подозреваю, что, не владея терминологией, Вы таким образом обозначили целый класс методов доступа к данным посредством btree-индекса (index full scan {ascending|descending}, index fast full scan, index range scan {ascending|descending}, index unique scan).
Эти методы работают по разному, но есть одно общее свойство: ни один из них не будет возвращать данные в порядке rowid, поскольку btree-индексы по природе своей упорядочены по атрибутам, входящим в индекс - это важно.
Подозреваю также, что с толку сбило упоминание о том, что btree отсортированы binary. Но осмысление этого замечание требует в дополнение к
концептам и руководствам по разработке осознания еще одного фолианта -
globalization support guide , без которого рассуждать на данные темы смысла нет.
Опустим пока тот незамысловатый факт, что индексы oracle одним btree не ограничиваются и включают в себя bitmap, function-based и доменные индексы (к примеру, Oracle Text и Oracle Spatial, про кастомные реализации ODCIIndex и говорить пока не стоит).
Не удивлюсь, если "select * from TABLE" уже и так возвращает строки в порядке rowid по умолчанию. Надо сильно извергаться, чтобы оправдать порядок отличный от этого.
Меньше знаешь - крепче спишь.
На поверхности:
- экстенты сегмента таблицы могут быть расположены в нескольких файлах данных
- доступ может быть распараллелен
- метод доступа может измениться
Кластер кластеру люпус эст.
Есть кластер как метод хранения данных, способный задать строкам разных таблиц один rowid.
Есть RAC, в котором и без того не очень простые процессы добычи данных становятся еще сложнее ввиду кластерных взаимодействий (cache fusion).
Общее замечание: oracle rdbms - штука сложная.
Очень сложная.
А еще - это черный ящик, в который мы иногда подглядываем через различные технологические отверстия.
Даже признанные специалисты с многолетним бэкграундом не всегда знают "как наше слово отзовется".
Потому не стоит делать серьезные выводы на основании пары простеньких экспериментов - Вы исследовали более чем ограниченную локацию и обобщения элементарно некорректны.
