Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
03.11.2015, 14:11
|
|||
---|---|---|---|
|
|||
varchar и плотность заполнения страниц данными |
|||
#18+
IB2007, страничка 4к, база была 15G, после бэкап-рестор с галочкой use all space стала 12 гигов Есть табличка, 42 миллиона записей, записи только добавляются. Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
во втором поле хранится guid в виде текста статистика по этой табличке такая Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Бэкап-рестор базе решил сделать увидев fill = 9%. Но ничего не изменилось. Как такое может быть? Варчары помогают? И попутный вопрос - что такое dp usage, которое для этой таблички 72% ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 14:17
|
|||
---|---|---|---|
|
|||
varchar и плотность заполнения страниц данными |
|||
#18+
Sia-Ori1Как такое может быть? Дофига страниц, заполненных полностью и одна, последняя, на которую записей не хватило. Что именно тебя напрягает? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 14:18
|
|||
---|---|---|---|
|
|||
varchar и плотность заполнения страниц данными |
|||
#18+
Dimitry Sibiryakov, Если все страницы заполнены, то fill ожидается в 90%, а он в десять раз меньше. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 14:45
|
|||
---|---|---|---|
varchar и плотность заполнения страниц данными |
|||
#18+
Sia-Ori1с галочкой use all space я напомню, что use all space (no reserve) рекомендуется только для баз в режиме read-only. Потому что для "модифицируемых БД" Firebird (и InterBase) специально оставляют примерно 30% свободного места на страницах данных чтобы туда поместились версии записей. Если же сделать no_reserve, то модификация данных вызовет необходимость создания новой страницы, и тогда записи и версии будут находиться на разных страницах, что плохо для производительности. Поэтому для read-write баз включать no reserve НЕ НАДО. Если вы хотите "сэкономить" 3 гига на 15-ти гигах, то это копеечная экономия. p.s. у InterBase XE3 ввели опцию no reserve, чтобы можно было указывать ее для конкретных редко изменяемых таблиц http://docs.embarcadero.com/products/interbase/IBXE3/Readme.html#new3E В FB включение-выключение опции возможно только для всей БД (как и у всех FB и предыдущих IB). Sia-Ori1VARCHAR(90) CHARACTER SET ASCII интересно, зачем это? Sia-Ori1Если все страницы заполнены, то fill ожидается в 90%, а он в десять раз меньше. Тогда просто не верьте gstat. Берете количество Data Pages, умножаете на размер страницы, делите на average record length. Получаете сколько записей при этих данных. Сравниваете с total records, получаете "процент заполнения". ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 15:05
|
|||
---|---|---|---|
|
|||
varchar и плотность заполнения страниц данными |
|||
#18+
kdv, спасибо, полегчало. Перемножением страниц и средней длины записей получается average fill = 0,82 int где-то переполняется и только. . 3 гига - не самоцель. Малый процент заполненности страниц сподвиг на сжатие. Сперва отресторил её в обычном режиме - не помогло. Со сжатием - те же 9%. а глючила только статистика. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 15:43
|
|||
---|---|---|---|
varchar и плотность заполнения страниц данными |
|||
#18+
kdvя напомню, что use all space (no reserve) рекомендуется только для баз в режиме read-only вполне можно рекомендовать и для баз append-only, что как раз случай ТС ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.11.2015, 22:08
|
|||
---|---|---|---|
varchar и плотность заполнения страниц данными |
|||
#18+
dimitr, есть некоторые админы или ДБА, которые страдают дурниной (не побоюсь этого слова) в отношении no_reserve. Производительность вставки и обновления они игнорируют, все жадятся до дискового пространства. Автору можно посоветовать обновиться до ХЕ3, и там уже управлять no_reserve на уровне таблиц, если ему так приспичилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.11.2015, 08:33
|
|||
---|---|---|---|
|
|||
varchar и плотность заполнения страниц данными |
|||
#18+
Ещё раз. В работе приложения видны торможения. Выборки до конца на клиента не вытягивает, и прочая ересь. Лезу в базу - вижу табличку которая по логике должна быть заполнена на 100%, но она почти пустая. Первая мысль - глюк, кто-то пишет-пишет-пишет в неё, а потом устраивает откат транзакции. И надо что-то делать. А так из 12 гигов базы эта таблица с индексами занимает 10. Гуиды в индексах очень хорошо место занимают. А в торможениях в итоге оказался виноват d-Linkовский хабчик по дороге от сервера к клиенту. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=40&mobile=1&tid=1562532]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 153ms |
0 / 0 |