|
|
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Не подскажет ли кто, каким образом без перезагрузки или фрагментации таблицы выяснить, сколько страниц ДЕЙСТВИТЕЛЬНО ЗАПОЛНЕНЫ ДАННЫМИ в этой таблице? Простой эксперимент: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. выдаёт следующее: Код: plaintext 1. 2. А после: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plaintext 1. 2. После фрагментации выяснилось, что 13 - 4 = 11 страниц были не заполнены данными. Вот как это выяснить без модификации таблицы? Или я ошибаюсь и старинцы были чем-то заполнены? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2005, 14:20 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Если для таблицы ни разу не выполнялся запрос UPDATE STATISTICS, пространство, занятое удаленными записями, повторно не используется. После серии DELETE некоторые страницы могут остаться на 90% пустыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2005, 17:09 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Да, кстати, извините, забыл сказать что пользуюсь IDS 7.31.UD6... Leonid BelovЕсли для таблицы ни разу не выполнялся запрос UPDATE STATISTICS, пространство, занятое удаленными записями, повторно не используется. После серии DELETE некоторые страницы могут остаться на 90% пустыми. К сожалению картина та же и после Код: plaintext Код: plaintext Ещё идеи есть? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2005, 17:46 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
"После фрагментации выяснилось, что 13 - 4 = 11 страниц были не заполнены данными. Вот как это выяснить без модификации таблицы? Или я ошибаюсь и старинцы были чем-то заполнены?" Для начала определимся с термином "данными". Как можно увидеть, и в первом и во втором случае ti_npdata=1, а это и есть именно "ДАННЫЕ", т.е. содержание таблицы и оно (кол-во страниц) не изменилось. В кол-во ti_npused входят все ИСПОЛЬЗУЕМЫЕ страницы, а сюдя относятся и индексные страницы (для версии 7.3х индексные страницы берутся из одного экстента с данными) и битмаповые страницы (как минимум одна всегда есть в экстенте), и блобовые (если BLOB-ы размещены в табличном пространстве) и remainder page ("остаточные", что ли :) , короче, для остатков длинных строк). ti_nptotal - все ВЫДЕЛЕННЫЕ страницы, среди которых есть и пока свободные, но не доступные другим таблицам. После удаления строк страницы остаются занятыми (учитываюися в ti_npused просто потому, что эти страницы помечены как "данные" и не могут использоваться как индексные, например), но вставка строк в них возможна и без update statistics. Другое дело, что оптимизатор по прежнему считает таблицу заполненной (если после заполнения таблицы выполнялся сбор статистики) и для чтения строк таблицы будет вынужден просканировать все страницы, которые считаются занятыми. Пока не сделаем новый update statistics. Есть чудная утилитка oncheck -pT ,которая покажет вам всю правду о занятых и свободных страницах таблицы даже в том случае, когда строки из таблицы удалены и в systabinfo в ti_npused показываются страницы как "используемые", хотя фактически они свободные для вставки строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2005, 19:59 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Спасибо, куча полезной информации. Но: :) Очередной эксперимент просто за душу берёт: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. vasilis Другое дело, что оптимизатор по прежнему считает таблицу заполненной (если после заполнения таблицы выполнялся сбор статистики) и для чтения строк таблицы будет вынужден просканировать все страницы, которые считаются занятыми. Пока не сделаем новый update statistics. Первая неприятность поджидала в п.N 6 - после DELETE FROM tmp1; oncheck радостно показывает именно ту статистику , какую хотелось бы получить, т.е. такую же статистику как и до заполнения таблицы, а systabinfo, и до и после выполнения UPDATE STATISTICS по прежнему считает что ti_npused = 13. :( vasilis Есть чудная утилитка oncheck -pT ,которая покажет вам всю правду о занятых и свободных страницах таблицы даже в том случае, когда строки из таблицы удалены и в systabinfo в ti_npused показываются страницы как "используемые", хотя фактически они свободные для вставки строк. Вот-вот, oncheck -pT "всю правду" показывает, а UPDATE STATISTICS не помагает... А как раскопать откуда oncheck -pT информацию тянет? ЗЫ: Заранее спасибо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 14:14 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Извините, закралась ошибка в oncheck free: Вместо Код: plaintext 1. должно быть Код: plaintext 1. т.е. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 15:09 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Bill'иОчередной эксперимент просто за душу берёт: А чем берет ? Все результаты предсказуемы, как для меня :) Следует отметить, что для полноты картины не хватает информации о размерах таблицы, взятых из systables, которая и обновляется как раз после UPDATE STATISTICS. Иначе в приведенном тобой эксперименте выполнение UPDATE STATISTICS не нужно (п.4, 6, 9) и ничего не дает (и не может дать в данном случае). И еще замечание - нельзя давать одно имя и таблице и индексу. Для 7-ки это не существенно (для вычислений), а вот для 9-ки это будут два разных tablespace, которые будут смешивать результаты. Bill'иПервая неприятность поджидала в п.N 6 - после DELETE FROM tmp1; oncheck радостно показывает именно ту статистику , какую хотелось бы получить, т.е. такую же статистику как и до заполнения таблицы, а systabinfo, и до и после выполнения UPDATE STATISTICS по прежнему считает что ti_npused = 13. :( Еще раз повторю, UPDATE STATISTICS не влияет на systabinfo и ранее уже объяснил, почему ti_npused не изменяется после удаления строк. Эти страницы уже отмечены в bitmap page, как занятые, и именно эти значения и присутствует в systabinfo. Надо ли их приводить в точное соответствие ? Как по мне, незачем (страницы то доступны для вставки строк) и будет много работы - при каждом удалении строки (!) надо проверять, а не последняя ли строка это на странице и после этого менять bitmap page, а ведь есть еще другие нити по вставке строк, и какая то уже могла получить адрес страницы и номер слота и т.п. Т.е. с точки зрения производительности и оптимизации работы с диском (а это присутствует повсюду внутри сервера) я понимаю, почему так сделано. Bill'иВот-вот, oncheck -pT "всю правду" показывает, а UPDATE STATISTICS не помагает... А как раскопать откуда oncheck -pT информацию тянет? Как откуда ? Непосредственно с диска и берет, анализируя каждую физическую страницу и на больших объемах это будет медленно и требовать большого вв/выв. Поэтому для сервера это и неприемлемо. А тебе, если очень нужно и очень точно, есть способ . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 18:53 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
vasilis И еще замечание - нельзя давать одно имя и таблице и индексу. Для 7-ки это не существенно (для вычислений), а вот для 9-ки это будут два разных tablespace, которые будут смешивать результаты. Не совсем понял про "смешивать результаты". Наверное потому, что с 9-кой шапочно знаком, а тут уже и 10-ка на подходе... Ладно, позже разберусь, но больше так делать не буду :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 20:04 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Bill'и А как раскопать откуда oncheck -pT информацию тянет? vasilis Как откуда ? Непосредственно с диска и берет, анализируя каждую физическую страницу и на больших объемах это будет медленно и требовать большого вв/выв. Поэтому для сервера это и неприемлемо. А тебе, если очень нужно и очень точно, есть способ . "А тебе, если очень нужно и очень точно, есть способ" - это "oncheck -pT"? А то недосказанность какая-то почувствовалась... Если да - на этот вопрос можно не отвечать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 20:05 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Вобщем, пока ничего оперативненького не получается. Зайдём с другой стороны: Имеем задачу по регулировке extent size и next size после длительной эксплуатации БД. Спешу обрадовать, с vasilisDBA_Tools я знаком. НО: Задача всплыла в новом ракурсе - необходимо отрегулировать extent size в связи с уменьшением на порядок объёма многих таблиц. Хотелось бы сделать инструмент, который делает всё это за один присест: выгрузка БД, колдование над скриптом, загрузка БД... Проблема как раз в пункте "колдование над скриптом" - пока выясняется, что он требует больших временных затрат (поскольку после чистки (DELETE) в рабочих таблицах информация в системных таблицах о свободных ИНДЕКСНЫХ страницах не обновляется, а точную оценку даёт только oncheck -pT, который работает долго, да и анализировать его вывод накладно. Собственно можно было бы рассчитать объём пространства, необходимого для загрузки таблицы, но у меня пока не получается ничего сделать с более-менее точной оценкой объёма, необходимого для создания индексов. Может кто-то знает, чем копать в эту сторону? Впрочем, обещаю внимательно рассмотреть любые предложения :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 20:07 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Прошу прощения, я не совсем понятно выразился про "свободные ИНДЕКСНЫЕ страницы"... Мне кажется, что именно из-за индексов не получается посчитать, сколько свободных страниц на самом деле на данный момент в extent'ах таблицы. Или ti_npdata - это количество занятых страниц С УЧЁТОМ ИНДЕКСОВ? 8-[ ] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 20:19 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Bill'иИли ti_npdata - это количество занятых страниц С УЧЁТОМ ИНДЕКСОВ? 8-[ ] Нет. Сюда входят только страницы с данными, я ранее подробно расписывал - читай внимательнее еще раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 22:29 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
Bill'и НО: Задача всплыла в новом ракурсе - необходимо отрегулировать extent size в связи с уменьшением на порядок объёма многих таблиц. А зачем ? Что, таблицы больше расти совсем не будут ? Или сильно большой дефицит пары гигабайт дискового пространства ? Или просто хочется сделать что то полезное для страны ? :) Bill'иХотелось бы сделать инструмент, который делает всё это за один присест: выгрузка БД, колдование над скриптом, загрузка БД... Если в базе нет фрагментации таблиц или хранения таблиц и индексов в разных ДБ-пространствах, а также таблиц с блокировкой на уровне строки (или их немного), то такой универсальный инструмент уже существует - называется dbexport (без опции -ss) и dbimport, который сам придумает нужный extent size и next size в размере 10% от extent size (если не ошибаюсь). Bill'и ...(поскольку после чистки (DELETE) в рабочих таблицах информация в системных таблицах о свободных ИНДЕКСНЫХ страницах не обновляется... Не только об индексных. Кстати, кажется существует автоматический механизм "схлопывания" пустых или полупустых индексных страниц, только не помню , когда он срабатывает - толи во время обновления, толи во время того же Update Statistics Bill'иСобственно можно было бы рассчитать объём пространства, необходимого для загрузки таблицы, но у меня пока не получается ничего сделать с более-менее точной оценкой объёма, необходимого для создания индексов. А что там считать ? Кол-во страниц = кол-во_строк/(Размер страницы-заголовок страницы)/(Размер ключа + 8 байт на ссылку) + немного на верхние уровни. Вроде так :) Точне можно посмотреть в Руководстве админа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2005, 22:48 |
|
||
|
Количество страниц, занятых таблицей c учётом пустых страниц
|
|||
|---|---|---|---|
|
#18+
vasilisА зачем ? Что, таблицы больше расти совсем не будут ? Или сильно большой дефицит пары гигабайт дискового пространства ? Вариантов с ростом таблиц есть много (напомню, что размеры уменьшились на порядок): Для одной БД - таблицы настолько НИКОГДА не вырастут - БД для макета Для второй - вырастут - но опять таки через 2-3 года эксплуатации. Для третьей - сегодня это 3-4 ГБ, а через год 15 Г, и опять таким страдай :( vasilis Если в базе нет фрагментации таблиц или хранения таблиц и индексов в разных ДБ-пространствах, а также таблиц с блокировкой на уровне строки (или их немного), то такой универсальный инструмент уже существует - называется dbexport (без опции -ss) и dbimport, который сам придумает нужный extent size и next size в размере 10% от extent size (если не ошибаюсь). Кстати не знал что dbimport сам "нужный extent size" прикидывает... И индексы в разных ДБ-пространствах, и таблиц с блокировкой на уровне строки немеряно... Вобщем, dbexport с -ss, а потом колдуем над скриптом, ВЫБРАСЫВАЯ из него EXTENT SIZE NEXT SIZE..., dbexport, и если после этого есть проблемы с количеством экстентов - см. исходную задачу :) vasilis А что там считать ? Кол-во страниц = кол-во_строк/(Размер страницы-заголовок страницы)/(Размер ключа + 8 байт на ссылку) + немного на верхние уровни. Вроде так :) Точне можно посмотреть в Руководстве админа. О! Там и глянем... vasilisИли просто хочется сделать что то полезное для страны ? :) Мне кажется, что тут как в анекдоте "Или ручками за 5 часов, или программу за 10 часов, а она потом ещё полчаса работать будет"... Но программу ведь не один раз использовать прийдётся. Попробую всё таки второй вариант :) О результатах собщу... После отпуска :) Всем спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2005, 15:26 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=33189691&tid=1608959]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
69ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 243ms |
| total: | 419ms |

| 0 / 0 |
