БД Oracle и физические сектора HDD

← →
Геннадий (2003-11-28 00:46) [0]

На днях моя деканша сказала, что в "простых" БД (типа Paradox) к данным в таблице обращаются по номеру поля или по имени поля. Это понятно. Но она говорит, что "вот Oracle" для ускорения доступа к данным требует ещё и указания секторов, в которые записано значение поля. И это всё (то есть помнить номера секторов) ложиться на широкие плечи программиста, создающего приложение, работающие с БД Oracle. Это что же за работа с HDD на физическом уровне?!

← →
Zacho (2003-11-28 01:10) [1]

Чушь. Покажи своей деканше любой учебник по SQL. И скажи ей, что Oracle - SQL-сервер.
А может она сектора с чем-нибудь другим перепутала ?

← →
mfender (2003-11-28 06:50) [2]

Деканша в высокие схвэры полезла.

← →
roottim (2003-11-28 08:03) [3]

> А может она сектора с чем-нибудь другим перепутала ?
скорее всего речь шла о кластеризации...
а теоретики слышали звон... и возможно перевели понятие кластеризации оракле в понятие кластеризации винта, ну там по сломанному телефону пришли к секторам...

← →
DenK_vrtz (2003-11-28 08:20) [4]

Деканша - это звучит гордо! :)

roottim (28.11.03 08:03) [3], скорее всего ты прав

← →
Sergey13 (2003-11-28 08:50) [5]

Ну, ИМХО, тут все слегка правы. Если работать с рав-девайсами то наверное кроме как секторами и не прочитаешь ничего. Но вот то что программер указывает какой сектор читать - это ИМХО чушь.

← →
asp (2003-11-28 09:00) [6]

Может, она что-то слышала про статистику. Но опять же программер ничего явно не указывает.

← →
Reindeer Moss Eater (2003-11-28 09:12) [7]

Деканша слышала звон, но очень недолго.

Действительно, в любой таблице Oracle есть псевдо столбец ROWID который, если не вдаваться в подробности указывает на физическое расположение строки на диске.

Ну и естественно, что ни о каком "запомнинании номеров секторов плечами программиста" и речи нет.

← →
Reindeer Moss Eater (2003-11-28 09:17) [8]

В одном она права. Выборка записи по ROWID - это очень быстро.

← →
hCat (2003-11-28 10:50) [9]

> Выборка записи по ROWID - это очень быстро.

Однако получать ROWID стоит только одновременно с локом соот записей. Поскольку строки могут мигрировать по блокам в результате update"ов выполненных другими сессиями, например.

> Но она говорит, что "вот Oracle" для ускорения доступа к
> данным требует ещё и указания секторов, в которые записано
> значение поля.

Ботва.

← →
BlackTiger (2003-11-28 14:39) [10]

Нда-а-а, сморозила ваша "деканша" чушь редкостную, этож надо было до такого додуматься. Хотя откуда ноги растут у этой байды - подозреваю, но чтоб САМ ПРОГРАММИСТ указывал откуда физически читать - это сильно. Я похожую вещь слышал про Microsoft Access, который хоть и файл-серверный, но не грузит сетку полным перетаскиванием всей базы (она-то в одном файля вся, как правило) по сетке между клиентом и сервером. Там вроде как используется случайный доступ к файлу и Access всегда знает место (смещение в файле БД), откуда и докуда нужно читать запись (или объект). Но это делается "ядром", а не пользователем!

← →
Zacho (2003-11-30 22:10) [11]

> BlackTiger © (28.11.03 14:39) [10]
> Там вроде как используется случайный доступ
> к файлу

Я, конечно, понял, что "случайный" - это буквальный перевод Random, но в данном контексте лучше использовать термин "произвольный", а то как представлю "случайный" доступ к файлу БД - так всякие кошмары мерещиться начинают :)

← →
Sergey13 (2003-12-01 08:55) [12]

2Reindeer Moss Eater © (28.11.03 09:12) [7]
>Действительно, в любой таблице Oracle есть псевдо столбец ROWID который, если не вдаваться в подробности указывает на физическое расположение строки на диске.

RowId все таки указывает на блок табличного пространства, а не на место на диске. Хотя через него Оракл разумеется и ищет его на диске.

2hCat (28.11.03 10:50) [9]
>Однако получать ROWID стоит только одновременно с локом соот записей. Поскольку строки могут мигрировать по блокам в результате update"ов выполненных другими сессиями, например

ROWID строки меняется только при EXP/IMP. В остальных случаях он постоянен.

2Геннадий © (28.11.03 00:46)
Сдается мне - невнимательно ты слушал. А теперь почтенную тетю обвиняешь. 8-)

← →
hCat (2003-12-01 12:02) [13]

2 Sergey13

> ROWID строки меняется только при EXP/IMP. В остальных случаях
> он постоянен

Вы неправы дважды:
Во-первых не только exp-imp меняет ROWID, но и исполнение команды тоже:
alter table ... move online tablespace ...
Поскольку в ROWID зашит ID файла данных, то при смене tablespace ROWID обязательно изменится.

Во-вторых update может менять rowid записи:
См Том Кайт "Оракл для профессионалов" Том 1 Глава 6 стр 264-265.
Теперь цитата, сокращенная, только ввиду лени, но не по существу:
"Интересно разобраться, что сервер Оракл будет делать, если [ранее rem hCat] перенесенную с левого блока в правый блок [рис в книге rem hCat] строку снова придется переносить. ... Сервер Оракл перенесет строку назад в исходный блок и, если места в нем достаточно оставит ее там. Если места в исходном блоке недостаточно, сервер Оракл перенест всю строку в другой блок и изменит адрес перенаправления в исходном блоке. Таким образом перенос строк создает только один уровень косвенной ссылки."

← →
Reindeer Moss Eater (2003-12-01 12:12) [14]

hCat

А теперь бы еще услышать о том, каким образом UPDATE влияет на смену страницы, в которой находится наша запись.

← →
Reindeer Moss Eater (2003-12-01 12:17) [15]

Да и вообще о чем спор?
Всем ясно, что деканша рассказала красивю и страшную легенду, которая впрочем основана на некоторых конкретных реальных фактах, сильно преувеличенных и преукрашенных преподавательским эпосом.

← →
Romkin (2003-12-01 12:21) [16]

2Reindeer Moss Eater Оракул версионник-блокировочник, так что update вполне может вызвать смену страницы :)
А деканша, по всей видимости, слышала это давно, когда программирование БД было тесно связано с физическим слоем...

← →
hCat (2003-12-01 12:24) [17]

2 Reindeer Moss Eater

> А теперь бы еще услышать о том, каким образом UPDATE влияет
> на смену страницы, в которой находится наша запись.

Я ответил на вопрос (см [13])? Так же смотри metalink.oracle.com

Doc ID: Note:122020.1
Subject: Row Chaining and Row Migration
Type: BULLETIN
Status: PUBLISHED
... skipped
Migration ----------
Occurs when a row that originally fitted into one data block is updated so that the overall row length increases, and the block"s free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row: the rowid of a migrated row does not change.
... skipped

← →
Reindeer Moss Eater (2003-12-01 12:28) [18]

Хорошо.
Тогда каким образом lock записи (уточнение из [9]) поможет ей остаться на месте?

← →
hCat (2003-12-01 12:31) [19]

2 Reindeer Moss Eater, Sergey13
Сорри похоже я облажался с пониманием текста - типичный пример - смотрим в книгу и видим фигу :(. Все-таки ссылка на строку при update остается в оригинальном блоке. Хотя откуда я взял, что строка из-за update меняет оригинальный блок... Буду делать пример для проверки. Все лень проклятая.

← →
hCat (2003-12-01 13:15) [20]

Пример сделал. Переноса строки в другой блок в простых условиях не добился. А взял это вот откуда, из Кайта же Том1 стр 265 "Учтите, что в случае использования фрагментированных [partition] таблиц этот адрес будет меняться..." Том 2 стр 136 "Это один из двух случаев (partition), когда ROWID может изменяется при изменении данных (другой - изменение первичного ключа таблицы, организованной по индексу [index organized table] )".
Так что запомнил я более-менее верно, только ко всем случаем сразу, без оговорок :)

← →
hCat (2003-12-01 13:33) [21]

Ответ на [18]
Имелась ввиду след конструкция, вид упрощенный:

select RowID into :Value from test where ID = 1 for update; ... -- здесь уже никто не сможет изменить запись и соответственно -- сбить RowID ... update test set ... where RowID = :Value

БД Oracle и физические сектора HDD Найти похожие ветки