Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Привет
Ааз
- Займется дефрагментацией пространства в блоке?

Все-таки, я думаю, будет это. Ведь рано или поздно придется это делать? Ведь поиск блока во freelist или ASSM, возможные сдвиг HWM, добавление нового экстента тоже потребуют немало затрат + еще накладные расходы при этом на манипуляции со словарем (например, tsq$) и всяческими заголовками сегмента, файла и пр.

С другой стороны, вполне может быть некий предел фрагментации блока и кол-ва свободного пр-ва в нем, в зависимости от которых Oracle может принимать один из двух последних вариантов.

Ааз
- Будет ли Oracle бить обновленный row piece на фрагменты дабы разместить их в имеющемся непрерывном пространстве того же блока?

Вот этого он делать не будет. Уверен на 99% ;-)

А вообще-то, надо поэкспериментировать. Могу заняться на следующей неделе. Хотя за бесплатно такую работу делать тяжело. Шутка, типа ;-)
2 июл 04, 18:05    [781477]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
Ааз
Хотелось сделать еще один шаг: при UPDATE может случиться ситуация, когда:
a) в блоке суммарно достаточно места для размещения обновленной версии фрагмента строки (row piece), как прописано в data header, поле "Available Free Space" (а также "Total Free Space" = +место от не полностью вычищенных транзакций и удаленных строк).
b) непрерывного пространства подходящего размера (End of Free Space - Start of Free Space +1) в блоке нет.

Вопросы:
- Будет ли Oracle бить обновленный row piece на фрагменты дабы разместить их в имеющемся непрерывном пространстве того же блока?
- Займется дефрагментацией пространства в блоке? (Это же ж лишнее redo размером с пару блоков. Да еще в undo лезть, за latch'и бороться...).
- Полезет в другой блок?

Oracle9i Database Concepts Release 2 (9.2)
2 Data Blocks, Extents, and Segments
Data Blocks Overview
Free Space Management
Availability and Compression of Free Space in a Data Block

Two types of statements can increase the free space of one or more data blocks: DELETE statements, and UPDATE statements that update existing values to smaller values. The released space from these types of statements is available for subsequent INSERT statements under the following conditions:

* If the INSERT statement is in the same transaction and subsequent to the statement that frees space, then the INSERT statement can use the space made available.
* If the INSERT statement is in a separate transaction from the statement that frees space (perhaps being run by another user), then the INSERT statement can use the space made available only after the other transaction commits and only if the space is needed.

Released space may or may not be contiguous with the main area of free space in a data block. Oracle coalesces the free space of a data block only when (1) an INSERT or UPDATE statement attempts to use a block that contains enough free space to contain a new row piece, and (2) the free space is fragmented so the row piece cannot be inserted in a contiguous section of the block. Oracle does this compression only in such situations, because otherwise the performance of a database system decreases due to the continuous compression of the free space in data blocks.
Markelenkov
А вообще-то, надо поэкспериментировать.
Автор оригинального вопроса, прочитав внимательно Сoncepts описал как работает данная функциональность -- рекомендую.
P.S:
Ааз
Интерес не праздный. Есть некие проблемы с системой типа order entry на туеву хучу операторов. UPDATE'ов и DELETE'ов хватает... Записи (в основном, столбцы типа NUMBER(x,y), большинство NULL'ы) сами по себе небольшого размера (не >2K), столбцов много, но меньше 255. UPDATE'ы могут затронуть произвольный столбец, где изначально был NULL.

Ясень пень, что там проблем много (в т.ч. с redo), но хотелось бы идентифицировать...
2 июл 04, 20:23    [781728]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Нео-2
Guest
Во дела. Получается сложность проблемы оказалась мнимой. И ее причина просто в невнимательном чтении Concepts.

to DBGC

Кто-то знает наизусть Шекспира и для каждой фразы может точно указать действие, к которой она относится. Вы по видимому наизусть знаете Concepts.
2 июл 04, 21:08    [781755]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
2 DBGC

Спасибо за цитату. Думаю, не все так просто, как написано в Concepts. Я в этом очередной раз убедился после разборок с index split в IOT.

<offtop>
Извините, но Ваша настойчивая борьба "за чистоту русского языка" уже вызывает нервный смех. Вы ищите проблему там, где ее нет. У Вас, кстати, тоже две пропущенные запятые в одном предложении.
</offtop>
2 июл 04, 21:27    [781772]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Нео-2
Guest
to Markelenkov

Это всего лишь профессиональное соперничество, ИМХО. Происходит не в первый раз. Ранее оно было например с AI, теперь Ааз на очереди:)

Как вывести имена тех таблиц схемы, где есть хотя бы 1 запись????
2 июл 04, 21:36    [781780]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
Markelenkov
2 DBGC
Спасибо за цитату. Думаю, не все так просто, как написано в Concepts. Я в этом очередной раз убедился после разборок с index split в IOT.
Это не оправдывает нечтение Concepts и документации. Я приведу цитату, я думаю что с ней будет сложно спорить:
https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=102689#767846

Ааз:
Начинающим советую:
- Concepts в качестве настольной книги (есть время - читай концепции)
Чтобы узнать что что-то просто или сложно Concepts нужно хотя бы прочитать, верно? Но читать нужно не только Concepts. IOT -- полезно рассмотреть списко открытых bugs на metalink, перед тем как делать какие-то выводы.

P.S.: спасибо на указание на мои ошибки!
2 июл 04, 21:59    [781791]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
> Вы по видимому наизусть знаете Concepts.

Нет, я не знаю concepts наизусть.

> Это всего лишь профессиональное соперничество, ИМХО.

Ну... с каких это пор цитирование документации превращалось в соперничество?

> Ранее оно было например с AI, теперь Ааз на очереди:)

Я лично не знаю, ни AI, ни Ааз, чтобы их выстраивать в очередь, я уже объяснял -- первично, мнение по вопросу, а не автор этого мнения. Ошибаться может любой, признавать ошибку не каждый -- отсюда все проблемы. Говоришь человеку "Пожалуйста, почитай Concepts", а он это воспринимает как "Ты, ...., почитай Concepts" и отвечает "Сам ты, ....". Чаще всего это называется "дискуссией".
2 июл 04, 22:38    [781810]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Oracle XPert
Member

Откуда:
Сообщений: 547
..................
2 июл 04, 23:00    [781826]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
2 ХPert

Не надо пож-та. Это мало кому интересно на оракловом форуме.
2 июл 04, 23:04    [781829]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Oracle XPert
Member

Откуда:
Сообщений: 547
King Regards for all!

Bye!
2 июл 04, 23:06    [781835]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
DBGroup Consulting
IOT -- полезно рассмотреть списко открытых bugs на metalink, перед тем как делать какие-то выводы.

Искал я и ноты, и описание багов. К сожалению, ничего, что бы объясняло алгоритм index block split у IOT и причины, по которым именно такой алгоритм был выбран, я не нашел. Может быть, искать не умею. Буду не против, если меня ткнут носом ;)
5 июл 04, 18:22    [785622]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Я
А вообще-то, надо поэкспериментировать. Могу заняться на следующей неделе. Хотя за бесплатно такую работу делать тяжело. Шутка, типа ;-)

Потратил сегодня полдня на исследования. Исследовал несекционированные heap-таблицы. Результат, как обычно, не претендует на истину в последней инстанции. Исследовалось поведение при вставке/обновлению данных в почти заполненный блок. Для меня в первую очередь представляли интерес случаи, когда для выполнения модификации блока требуется создание дополнительного ITL (в блоке есть незавершенные транзакции и нет свободных ITL, но maxtrans допускает рост их кол-ва), и случай сжатых таблиц (Oracle 9.2, опция compress).

Сухой остаток. Багов не обнаружил, необычного поведения тоже. Все, как расписано в доке. Из интересного выяснил следующее:

1) Если в рамках одной транзакции строка мигрировала в другой блок (и это может случиться неоднократно) и эта транзакция завершается откатом, то строка возвращается назад в исходный блок (но не обязательно в то же самое место). Если транзакция фиксируется - то все, как обычно - строка останется мигрировавшей и подчиняется известным правилам. Насколько я понял, этот подход применяется для всех типов таблиц, B*tree-индексов и возможно для других типов объектов.

2) В сжатый блок данных (Oracle 9.2, опция compress) данные не вставляются, даже если в этом блоке есть место. В этом случае вставка осуществляется в новый блок.

3) В случае обновления строки в сжатом блоке она всегда мигрирует в другой, несжатый блок.

Особенно интересными мне представляются пункты 2) и 3), предостерегающие от необдуманного использования опции сжатия для модифицируемых таблиц/секций.

Ааз
Хотелось сделать еще один шаг: при UPDATE может случиться ситуация, когда:
a) в блоке суммарно достаточно места для размещения обновленной версии фрагмента строки (row piece), как прописано в data header, поле "Available Free Space" (а также "Total Free Space" = +место от не полностью вычищенных транзакций и удаленных строк).
b) непрерывного пространства подходящего размера (End of Free Space - Start of Free Space +1) в блоке нет.

Могу теперь с большей уверенностью ответить:

Ааз
- Будет ли Oracle бить обновленный row piece на фрагменты дабы разместить их в имеющемся непрерывном пространстве того же блока?

Если столбцов<=255 - то нет. Если столбцов>255 - то будет бить всегда, независимо от доступности пространства.
Ааз
- Займется дефрагментацией пространства в блоке? (Это же ж лишнее redo размером с пару блоков. Да еще в undo лезть, за latch'и бороться...).
Да, займется дефрагментацией пространства в блоке. Естественно, должно быть достаточно места для строки с байтами длины и служебными 2-мя байтами, +3 байта на directory entry + 24 байта на случай добавления ITL. И свободного пр-ва должно быть не меньше 11 байт (эффект minimum row length).
Ааз
- Полезет в другой блок?
Нет, если выполняются предыдущие условия, то есть, места достаточно в том числе и на создание нового ITL в случае необходимости. Да, если блок сжат. Про этот случай ничего ни в доках, ни в каких-либо статьях я не встречал. Со сжатыми блоками еще повожусь, вдруг еще есть подводные камни или какие-нибудь нюансы. Как и ожидалось, не все так тривиально в нашем царстве...

P.S. Андрей, с тебя пиво ;)
9 июл 04, 18:23    [797811]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
u_gray
Member

Откуда: Москва
Сообщений: 170
Markelenkov

2) В сжатый блок данных (Oracle 9.2, опция compress) данные не вставляются, даже если в этом блоке есть место. В этом случае вставка осуществляется в новый блок.

3) В случае обновления строки в сжатом блоке она всегда мигрирует в другой, несжатый блок.


Действительно, 2) и 3) считаю чрезвычайно полезной информацией.

Markelenkov

P.S. Андрей, с тебя пиво ;)


Похоже мне тоже не отвертеться ;))
9 июл 04, 18:33    [797847]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
Markelenkov
2) В сжатый блок данных (Oracle 9.2, опция compress) данные не вставляются, даже если в этом блоке есть место. В этом случае вставка осуществляется в новый блок.

3) В случае обновления строки в сжатом блоке она всегда мигрирует в другой, несжатый блок.
Oracler Database Concepts 10g Release 1 (10.1)
5 Schema Objects

Table Compression

Oracle's table compression feature compresses data by eliminating duplicate values in a database block. Compressed data stored in a database block (also known as disk page) is self-contained. That is, all the information needed to re-create the uncompressed data in a block is available within that block. Duplicate values in all the rows and columns in a block are stored once at the beginning of the block, in what is called a symbol table for that block. All occurrences of such values are replaced with a short reference to the symbol table.

With the exception of a symbol table at the beginning, compressed database blocks look very much like regular database blocks. All database features and functions that work on regular database blocks also work on compressed database blocks.

Database objects that can be compressed include tables and materialized views. For partitioned tables, you can choose to compress some or all partitions. Compression attributes can be declared for a tablespace, a table, or a partition of a table. If declared at the tablespace level, then all tables created in that tablespace are compressed by default. You can alter the compression attribute for a table (or a partition or tablespace), and the change only applies to new data going into that table. As a result, a single table or partition may contain some compressed blocks and some regular blocks. This guarantees that data size will not increase as a result of compression; in cases where compression could increase the size of a block, it is not applied to that block.

Using Table Compression

Compression occurs while data is being bulk inserted or bulk loaded. These operations include:

* Direct path SQL*Loader
* CREATE TABLE and AS SELECT statements
* Parallel INSERT (or serial INSERT with an APPEND hint) statements

Existing data in the database can also be compressed by moving it into compressed form through ALTER TABLE and MOVE statements. This operation takes an exclusive lock on the table, and therefore prevents any updates and loads until it completes. If this is not acceptable, then Oracle's online redefinition utility (DBMS_REDEFINITION PL/SQL package) can be used.

Data compression works for all data types except for all variants of LOBs and data types derived from LOBs, such as VARRAYs stored out of line or the XML data type stored in a CLOB.

Table compression is done as part of bulk loading data into the database. The overhead associated with compression is most visible at that time. This is the primary trade-off that needs to be taken into account when considering compression.

Compressed tables or partitions can be modified the same as other Oracle tables or partitions. For example, data can be modified using INSERT, UPATE, and DELETE statements. However, data modified without using bulk insertion or bulk loading techniques is not compressed. Deleting compressed data is as fast as deleting uncompressed data. Inserting new data is also as fast, because data is not compressed in the case of conventional INSERT; it is compressed only doing bulk load. Updating compressed data can be slower in some cases. For these reasons, compression is more suitable for data warehousing applications than OLTP applications. Data should be organized such that read only or infrequently changing portions of the data (for example, historical data) is kept compressed.
Markelenkov
Могу теперь с большей уверенностью ответить:
Markelenkov
Все, как расписано в доке
Вывод: следует почитать Concepts (как правильно говорил А.Криушин) + документацию доступную на Metalink, по этой теме можно почитать/нужно 228082.1.
9 июл 04, 21:04    [798069]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
2 DBGroup Consulting

Спасибо за цитату. В доке по 10g чуть подробнее все расписано о сжатии таблиц - это, конечно, радует. Только, к сожалению, ничего нового для меня нет в процитированном куске. Я ранее достаточно подробно изучил процесс преобразования несжатой таблицы в сжатую. Знаю, что блоки одной таблицы/секции могут быть и сжатыми и несжатыми и пр. и пр.

Сегодня же я изучал алгоритмы модификации сжатых блоков. Были сомнения по следующим вопросам:

1) Что случится, если в сжатом блоке сделать обновление строки на идентичную (при этом в блоке есть достаточно свободного места).
Предполагаемые варианты:
a) строка в блоке не изменится
b) строка в блоке будет несжата
c) строка в блоке переместится в свободное место и будет сжата (этот вариант, оказывается, отметает дока по 10g)
d) строка мигрирует

Верный ответ - d). В случае действительного изменения строки (не на саму себя) отпадает вариант a), но другие три тоже неочевидны. Документация конкретного ответа не дает.

2) Что случится, если попытаться вставить строку в сжатый блок, в котором достаточно свободного места.
Предполагаемые варианты:
a) строка в блоке будет сжата, если ее данные, скажем так, совпадают с данными префикса сжатого блока. Этот вариант отвергается документацией и является достаточно очевидным.
b) строка будет вставлена в блок несжатой (это подтверждает дока по 10g, но не разъясняет, в какой блок)
c) строка не будет вставляться в этот блок, а будет вставлена в другой, причем несжатой, т.к. это не bulk insert.

Верный ответ - c). В этом случае документация тоже конкретного ответа не дает.

Делаю для себя очередной раз вывод - чтение документации обязательно, но более глубокое и детальное изучение темы почти всегда дает что-то новое и зачастую весьма и весьма любопытное.

P.S. Благодарю за конструктивную дискуссию и буду признателен на указание возможных ошибок/неточностей в моих рассуждениях и экспериментах.
9 июл 04, 22:37    [798158]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
Markelenkov
Только, к сожалению, ничего нового для меня нет в процитированном куске.
Это не для кого-то лично, это для всех. Я говорю что проще было-бы почитать, разобраться что выглядит "подозрительно", а сделать "предположения", провести эксперемент, убедиться в результатах... могу себе представить последствия вашего подхода при работе с мирным атомом, сначала "жахним", а потом проверим... ;)
1) Что случится, если в сжатом блоке сделать обновление строки на идентичную (при этом в блоке есть достаточно свободного места).
документация

Compression occurs while data is being bulk inserted or bulk loaded. These operations include:

* Direct path SQL*Loader
* CREATE TABLE and AS SELECT statements
* Parallel INSERT (or serial INSERT with an APPEND hint) statements

...data modified without using bulk insertion or bulk loading techniques is not compressed.


Разумеется, строка смигрирует. Документация даёт конкретный ответ. При conventional operations компрессии данных не происходит, следовательно, если нельзя сделать компрессию данных в компрессированном блоке, то стоку нужно только в другой блок "перенести", без компрессии, такой перенос называется migration.
Markelenkov
c) строка не будет вставляться в этот блок, а будет вставлена в другой, причем несжатой, т.к. это не bulk insert.
Об этом написано в документации, я её цитировал выше.

На оба вопроса ответ был в документации.
9 июл 04, 23:08    [798186]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Markelenkov
Андрей, с тебя пиво ;)
Стока пива, скока я тебе должен за это исследование, тебе не выпить . Но как скажешь, барин. А то можно и по коньячку вдарить ;-).


DBGroup Consulting
могу себе представить последствия вашего подхода при работе с мирным атомом, сначала "жахним", а потом проверим... ;)
УУпппсссс.... Нет уж. Лучше я буду язык коверкать. См. п.II ниже.


2 DBGroup Consulting:

I. Критика и комментарии у вас (за исключением наезда, процитированного выше в этом постинге) качественные (без шуток). Они важны и полезны для всех участников форума. Вот только... даже при наличии где-либо в доступном источнике готового ответа (например, в Concepts)...

Иногда задать неочевидный вопрос и проработать публично ответ на него полезней, чем ... просто читать подряд даже очччень правильные документы. Признайтесь честно, вы ведь Concepts стали внимательно вычитывать ПОСЛЕ того, как были заданы первые вопросы и появились первые ответы.

II. "Ошибаться может любой, признавать ошибку не каждый -- отсюда все проблемы." Или я не признавал ошибок на этом форуме? Могу добавить - конечно, я не прав, что не запустил search по Concepts по шаблону "migrat". Признаю свою ошибку, которую вы так уместно исправили.


III. "Ребята, давайте жить дружно" (из известного мультика).
10 июл 04, 04:23    [798296]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18482
2 Markelenkov
Пункт 2 и 3 для меня очень важны - большое спасибо

2 DBGroup Consulting
Критика это конечно хорошо, но вы и не подтвердили и не опровергли результатов
Я стараюсь не ввязываться в эти гнилые базары но вот вам цитата:
АБС Улитка на склоне
Можно понимать его так, что появляются эти знаменитые "зато": алкоголик, зато отличный специалист; распутник, зато отличный проповедник; вор ведь, выжига, но зато какой администратор! Убийца, зато как дисциплинирован, предан... А можно понимать прогресс как превращение всех в людей добрых и честных. И тогда мы доживем когда-нибудь до того времени, когда будут говорить: специалист он, конечно, знающий, но грязный тип, гнать его надо...
10 июл 04, 04:59    [798302]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
1. Если речь идёт о "работе с мирным атомом", то я честно говорю, что аналогия была юмористическая и не должна рассматриваться как "наезд". Если же г. Маркеленков был обижен, то я готов принести ему свои извинения, хотя мне непонятно, какое имеет отношение к г.Криушину.

2. Concepts по 10g, я прочитал когда 10g стал доступен для beta тестирования, т.е. [чуть] более года назад. Считаю что потратить 3 минуты на прочтение главы и 10 минут для осознания того что там написано, лучше чем "Потратил сегодня полдня на исследования." Если для достижения результата нужно 13 минут и 3-4 часа, какой из способов достижения результата будет выбран?

3. Я не говорил что лично Андрей Криушин в чём-то не признаётся, я сказал что:
"...первично, мнение по вопросу, а не автор этого мнения.", т.е. мне всё равно кто это говорит, если что-то говориться технически неправильно, неверно, есть способы найти лучшее решение, существует лучшее решение -- я оставляю за собой право сделать комментарий.

"Говоришь человеку "Пожалуйста, почитай Concepts", а он это воспринимает как "Ты, ...., почитай Concepts" и отвечает "Сам ты, ....".

Похоже именно так и получилось...

Вячеслав Любомудров
Критика это конечно хорошо, но вы и не подтвердили и не опровергли результатов
Это очень спорное утверждение, вы прочитали указанные ссылки? Похоже что нет. Сделайте это. Если же прочитали и не поняли, не до конца разобрались -- скажите, я объясню всё простыми, доступными словами.
10 июл 04, 05:19    [798306]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
DBGroup Consulting
Разумеется, строка смигрирует. Документация даёт конкретный ответ. При conventional operations компрессии данных не происходит, следовательно, если нельзя сделать компрессию данных в компрессированном блоке, то стоку нужно только в другой блок "перенести", без компрессии, такой перенос называется migration

Такой вывод можно сделать, если знать, что в сжатом блоке все строки всегда должны храниться сжатыми. Если где об этом и написано - значит я невнимательно читал.

DBGroup Consulting
Markelenkov
c) строка не будет вставляться в этот блок, а будет вставлена в другой, причем несжатой, т.к. это не bulk insert.
Об этом написано в документации, я её цитировал выше.

На оба вопроса ответ был в документации.

На мой взгляд, документация утверждает, что строка будет вставлена несжатой. А вот в какой блок она будет вставлена - об этом умалчивается.

И еще, как мне кажется, в документации стоило бы явно написать, что строка мигрирует, тогда и этих двусмысленностей бы не было, и рядовых пользователей этого предостерегло бы более внятно от использования опции compress в OLTP.

DBGroup Consulting
могу себе представить последствия вашего подхода
при работе с мирным атомом, сначала "жахним", а потом проверим... ;)

Мы с мирным атомом не работаем. Мирный - он для трусов ;-) А ""жахним", а потом проверим" - это традиционный подход в нашем деле ;-)

DBGroup Consulting
Если же г. Маркеленков был обижен, то я готов принести ему свои извинения

Да с какой это стати я должен обижаться? Я не вижу повода для обид. Более того, повторяю, я рад развернувшейся дискуссии - мне гораздо интересней общаться со специалистами, чем отвечать на простые вопросы.

P.S. Документацию по 10g я не читал, т.к. предпочитаю 1) читать ее, имея всю под рукой; 2) читать, имея установленный 10g. Просто иначе у меня в голове получается каша из версий и фичей.

P.P.S. Ворованным Oracle или скачанным с OTN мы не пользуемся. Планируется покупка 10g, но дело пока затянулось до осени.
10 июл 04, 07:51    [798317]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
u_gray
Действительно, 2) и 3) считаю чрезвычайно полезной информацией.


Вячеслав Любомудров
Пункт 2 и 3 для меня очень важны - большое спасибо


Не за что. Это я делаю, в основном, для себя. Мне это интересно. Результатами делюсь с другими - вдруг кому-нибудь тоже интересно.
10 июл 04, 07:55    [798318]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
Markelenkov
На мой взгляд, документация утверждает, что строка будет вставлена несжатой. А вот в какой блок она будет вставлена - об этом умалчивается.
Почитайте, пожалуйста, что такое Direct-Path load и куда он "ставляет" строки, см цитату выше, о:

* Direct path SQL*Loader
* CREATE TABLE and AS SELECT statements
* Parallel INSERT (or serial INSERT with an APPEND hint) statements

Я думаю этот пункт позволит развеять сомнения по-поводу ставки окончательно.
10 июл 04, 08:19    [798326]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
DBGroup Consulting
Member

Откуда: http://dbgroup.ru
Сообщений: 711
... "что строка будет вставлена несжатой"

Сжимается-то не сама строка, сжимается группа строк в блоке, простая вставка в этот блок означала бы uncompress и compress блока, а этого не делается для convetional insert -- это очень CPU intensive операция:

"a single table or partition may contain some compressed blocks and some regular blocks."

Речь идёт о блоках, который бывают двух типов: compressed и regular.

Я думаю всё понятно.
10 июл 04, 08:41    [798330]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Markelenkov
...от использования опции compress в OLTP.

Пытался сократить текст, но это вносит неточность. Следут понимать как "от необдуманного использования опции сжатия для (часто) модифицируемых таблиц/секций". В чистом OLTP однозначно использовать не рекомендуется.

DBGroup Consulting
Я думаю этот пункт позволит развеять сомнения по-поводу ставки окончательно


1) создаю таблицу, наполняю тестовыми данными, причем такими, что часть строк сжимается, часть - не сжимается
2) alter table ... move compress
3) сжатая таблица занимает 1 блок. Причем в несжатом виде она занимала > 1 блока (таблица, имеющая 1 блок, как известно, не сжимается - вот об этом можно додуматься, прочитав документацию). Кроме этого в блоке есть свободное место, достаточное для размещения еще нескольких строк. HWM находится сразу за первым блоком
4) выполняем обычный, serial insert в эту таблицу.

Строка будет вставлена не сжатой. Вот это документация утверждает четко и недвусмысленно. Мне казалось более очевидным и естественным, что строка должна вставляться в этот блок. Просто в нем появится еще одна несжатая строка. Как результат - не надо сдвигать HWM, меньше redo и т.д. Но алгоритм другой. Почему - другой вопрос, связанный с кухней сжатия блоков. Видимо, реализовать это сложно. В случае же update происходит куда более неприятная вещь - миграция.

Везде, где это явление может случиться, документация акцентирует внимание на понятии сцепленных и мигрировавших строк в плане их серьезного влияния на производительность. Здесь же об этом - ни слова.

Объясните мне, пожалуйста, как на основании процитированного Вами текста документации можно сделать вывод об алгоритмах вставки и обновления строк в данном случае? Если, конечно, есть время и желание. Я действительно не могу понять, как можно, прочитав данный текст, быть уверенным именно в таком поведении Oracle, а не догадываться.
10 июл 04, 09:15    [798336]     Ответить | Цитировать Сообщить модератору
 Re: Доступ к свободному пространству в блоке данных и его оптимизация  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Упс... Пока писал, появился новый ответ.

Тогда получается, что сжатый блок Oracle рассматривает вроде как "неделимое целое", как "единицу хранения" сжатых данных и пытается минимизировать изменения в нем, потому что он всегда считает это очень дорогой операцией и даже допускает миграцию. Вот в таком ключе становится все понятно. Видимо, любые изменения в сжатом блоке крайне дороги - отсюда и такое поведение.

Спасибо за наводку.
10 июл 04, 09:28    [798339]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить