IBAnalyst: Разумевање ваше базе података

Дмитриј Кузменко, [email protected], последње ажурирање 31. март 2014.

Радим са InterBase-ом од 1994. године. Тада је већина база података била мала и није захтевала никакво подешавање. Наравно, било је прилика када сам морао да променим ibconfig на серверу и реконфигуришем хардвер или ОС, али то је било скоро све што сам могао да урадим за подешавање перформанси.

Пре четири године, наша компанија је почела да пружа техничку подршку и обуку за InterBase кориснике. Рад са многим продукционим базама података такође ме је научио многим различитим стварима. Међутим, већина онога што сам научио односила се на апликације - коришћење параметара трансакција, оптимизацију упита и скупова резултата.

Наравно, дуго сам знао за gstat - алат који даје информације о статистици базе података. Ако сте икада погледали gstat излаз или прочитали opguide.pdf о њему, знали бисте да статистички излаз изгледа као гомила бројева и ништа више. Ок, можете открити информације о фрагментацији за одређену табелу или индекс, али које још корисне информације се могу добити?

На срећу, пре рада са InterBase-ом, занимале су ме различите структуре података, како се чувају и које алгоритме користе. То ми је помогло да протумачим излаз gstat-а. Тада сам одлучио да напишем алат који би могао да анализира gstat излаз како би помогао у подешавању базе података или барем идентификовао узрок проблема са перформансама.

Дуга прича, али исход је био да је IBAnalyst створен. Упркос мом искуству, и даље ми омогућава да пронађем веома занимљиве ствари или проблеме са перформансама у различитим базама података.

Реални системи имају перформансе у току рада које флуктуирају као талас. Амплитуда таквих „таласа“ може бити ниска или висока, тако да можете видети како се перформансе разликују из дана у дан (или из сата у сат). Стварне перформансе зависе од многих фактора, укључујући дизајн апликације, конфигурацију сервера, конкурентност трансакција, верзијско смеће у бази података и тако даље. Да бисте сазнали шта се дешава у бази података (и позитивне и негативне аспекте перформанси), требало би барем с времена на време погледати статистику базе података.

Погледајмо могућности IBAnalyst-а. IBAnalyst може узети статистику из gstat-а или Services API-ја и саставити их у извештај који вам даје потпуне информације о бази података, њеним табелама и индексима. Има упозорења на месту која су доступна током прегледа статистике; такође укључује коментаре са саветима и извештаје са препорукама.

Информације о бази података

Слика 1 Преглед статистике базе података

Преглед приказан на Слици 1 пружа опште информације о вашој бази података. Приказана упозорења или коментари засновани су на пажљиво прикупљеном знању добијеном из великог броја реалних продукционих база података.

Напомена: Све слике у овом чланку садрже gstat статистику која је узета из реалне продукционе базе података (уз дозволу њених власника).

Као што сам већ рекао, сирова статистика базе података изгледа нејасно и тешко је тумачива. IBAnalyst јасно истиче све потенцијалне проблеме жутом или црвеном бојом, а детаљ проблема се може прочитати једноставним постављањем курсора на одговарајући унос и читањем савета који се приказује. Шта можемо открити из горње слике? Ово је база података дијалекта 3 са величином странице од 4096 бајтова. Пре шест до осам година програмери су користили подразумевану величину странице од 1024 бајта, али у новије време тако мала величина странице може довести до многих проблема са перформансама. Пошто ова база података има величину странице од 4k, не приказује се упозорење, јер је ова величина странице прихватљива.

Затим можемо видети да је параметар Forced Write подешен на OFF и означен црвеном бојом. InterBase 4.x и 5.x су подразумевано имали овај параметар укључен. Forced Writes је сам метод кеша за писање: када је укључен, одмах записује промењене податке на диск, али OFF значи да ће записи бити чувани непознато време од стране оперативног система у његовом кешу датотека. InterBase 6 креира базе података са Forced Writes искљученим.

Зашто је ово означено црвеном бојом у IBAnalyst извештају? Одговор је једноставан - коришћење асинхроних уписа може изазвати оштећење базе података у случају квара напајања, ОС-а или сервера.

Савет: Занимљиво је да модерни HDD интерфејси (ATA, SATA, SCSI) не показују велику разлику у перформансама са Forced Write укљученим или искљученим(1).

Следеће у извештају је мистериозни „sweep interval“. Ако је позитиван, поставља величину размака између најстарије (2) и најстарије snapshot трансакције, при чему се мотор упозорава на потребу покретања аутоматског сакупљања смећа. На неким системима, достизање овог прага ће изазвати ефекат „изненадног губитка перформанси“, и као резултат тога понекад се препоручује да се sweep interval постави на 0 (потпуно онемогућавање аутоматског чишћења). Овде је sweep interval означен жутом бојом, јер је вредност sweep размака негативна, што може бити у InterBase 6.0, Firebird и Yaffil статистици, али не у InterBase 7.x. Када је вредност sweep размака већа од sweep интервала (ако sweep интервал није 0), унос у извештају за sweep интервал ће бити означен црвеном бојом са одговарајућим саветом.

Следећих 8 редова ћемо размотрити као групу, јер сви приказују аспекте стања трансакција базе података:

Најстарија трансакција је најстарија непотврђена трансакција. Сви нижи бројеви трансакција су за потврђене трансакције, и ниједна верзија записа није доступна за такве трансакције. Бројеви трансакција виши од најстарије трансакције су за трансакције које могу бити у било ком стању. Ово се такође назива „најстарија занимљива трансакција“, јер се замрзава када се трансакција заврши са rollback-ом, и сервер не може да поништи њене промене у том тренутку.
Најстарији snapshot - најстарија активна (тј. још непотврђена) трансакција која је постојала на почетку трансакције која је тренутно најстарија „занимљива“ трансакција. Означава најнижи број snapshot трансакције која је заинтересована за верзије записа.
Најстарија активна - најстарија тренутно активна трансакција (3).
Следећа трансакција - број трансакције који ће бити додељен новој трансакцији.
Активне трансакције - IBAnalyst ће дати упозорење ако је број најстарије активне трансакције 30% нижи од дневног броја трансакција. Статистика не говори да ли постоје било које друге активне трансакције између најстарије активне и следеће трансакције, али такве трансакције могу постојати. Обично, ако најстарија активна трансакција „заглављена“, постоје два могућа узрока: а) нека трансакција је активна дуго времена или б) дизајн апликације дозвољава трансакцијама да трају дуго. Оба узрока спречавају сакупљање смећа и троше ресурсе сервера.
Трансакције по дану - ово се израчунава из следеће трансакције, подељено са бројем дана протеклих од креирања базе података до тренутка када је статистика преузета. Ово може бити тачно само за продукционе базе података, или за базе података које се периодично обнављају из резервне копије, што узрокује ресетовање бројања трансакција.

Као што сте већ научили, ако постоје било каква упозорења, она су приказана као обојени редови, са јасним, описним саветима како да поправите или спречите проблем.

Треба напоменути да статистика базе података није увек корисна. Статистика прикупљена током рада и операција одржавања може бити бесмислена.

Немојте прикупљати статистику ако:

Управо сте обновили своју базу података
Извршена је резервна копија (gbak -b db.gdb) без -g прекидача
Недавно је извршено ручно чишћење (gfix -sweep)

Статистика коју добијете у таквим приликама биће практично бескорисна. Такође је тачно да током нормалног рада могу постојати тренуци када је база података у савршеном стању, на пример, када апликације праве мање оптерећење базе него обично (корисници су на ручку или је мирно доба у пословном дану).

Како можете знати када нешто није у реду са базом података?

Ваше апликације могу бити тако добро дизајниране да ће увек радити са трансакцијама и подацима исправно, не правећи празнине у чишћењу, не акумулирајући много активних трансакција, не држећи дуготрајне снимке и тако даље. Обично се то не дешава (извините, колеге).

Најчешћи разлог је што програмери тестирају своје апликације покрећући само два или три истовремена корисника. Када се апликација затим користи у производном окружењу са петнаест или више истовремених корисника, база података може да се понаша непредвидиво. Наравно, мултикориснички режим може да ради добро јер се већина мултикорисничких конфликата може тестирати са две или три истовремено покренуте апликације. Међутим, са већим бројем корисника, могу настати проблеми са сакупљањем смећа. Такви потенцијални проблеми могу се ухватити ако прикупљате статистику базе података у правим тренуцима.

Информације о табелама

Погледајмо још један пример излаза из IBAnalyst-а.

![](/images/article_IBAnalyst (1).jpg)

Слика 2 Статистика табела

IBAnalyst приказ статистике табела је такође веома користан. Може показати које табеле имају много верзија записа, где је направљен велики број ажурирања/брисања, фрагментоване табеле, са фрагментацијом узрокованом ажурирањем/брисањем или blob-овима, и тако даље. Можете видети које табеле се често ажурирају, и која је величина табеле у мегабајтима. Већина ових упозорења је прилагодљива.

У овом примеру базе података постоји неколико проблема. Прво, жута боја у колони VerLen упозорава да је простор који заузимају верзије записа већи од оног који заузимају сами записи. То може бити резултат ажурирања много поља у запису или масовног брисања. Погледајте редове у којима је колона MaxVers означена плавом бојом. То показује да се чува само једна верзија по запису и да је проблем последица масовног брисања. Вредност у колони Versions показује колико је записа обрисано.

Дуготрајне активне трансакције које спречавају сакупљање смећа су главни разлог за деградацију перформанси. За неке табеле може постојати много верзија које су још увек „у употреби“. Сервер не може да одлучи да ли су оне заиста у употреби, јер активне трансакције потенцијално требају било коју или све ове верзије. Сходно томе, сервер не сматра ове верзије смећем, и потребно је све дуже и дуже да се конструише исправан запис из много верзија када год трансакција прочита. На слици 2 можете видети две табеле које имају број верзија три пута већи од броја записа. Користећи ове информације, такође можете проверити да ли је чињеница да ваше апликације тако често ажурирају ове табеле намерна или због грешке.

Приказ индекса

Индекси се користе од стране мотора базе података за спровођење примарног кључа, страног кључа и јединствених ограничења. Они такође убрзавају проналажење података. Јединствени индекси су најбољи за проналажење података, али ниво користи од нејединствених индекса зависи од разноврсности индексираних података.

На пример, погледајте ADDR_ADDRESS_IDX6. Прво, само име индекса сугерише да је креиран ручно. Ако је статистика узета преко Services API-ја са метаподацима, можете видети које су колоне индексиране (у IBAnalyst 1.83 и новијим). За индекс који се испитује можете видети да има 34999 кључева, TotalDup је 34995 и MaxDup је 25056. Обе колоне дупликата су означене црвеном бојом. То је зато што постоје само 4 јединствене вредности кључа међу свим кључевима у овом индексу, као што се види из колоне Uniques. Штавише, највећи ланац дупликата (кључ који показује на записе са истом вредношћу колоне) је 25056 - тј. скоро сви кључеви чувају једну од четири јединствене вредности. Као резултат, овај индекс би могао:

Смањити брзину процеса враћања. Добро, тридесет пет хиљада кључева није велика ствар за модерне базе података и хардвер, али утицај треба приметити.
Успорити сакупљање смећа. Индекси са малим бројем јединствених вредности могу ометати сакупљање смећа до десет пута у поређењу са потпуно јединственим индексом. Овај проблем је решен у InterBase 7.1/7.5 и Firebird 2.0.
Произвести непотребна читања страница када оптимизатор чита индекс. То зависи од вредности која се тражи у одређеном упиту - претрага по индексу који има већу вредност за MaxDup биће спорија. Претрага по вредности на колони која има мање дупликата биће бржа, али само ви знате да је колона индексирана.

Зато IBAnalyst скреће вашу пажњу на такве индексе, означавајући их црвеном и жутом бојом, и укључујући их у извештај Препоруке. Нажалост, већина „лоших“ индекса се аутоматски креира за спровођење ограничења страног кључа. У неким случајевима овај проблем се може решити спречавањем, користећи тригере, брисања или ажурирања примарног кључа у табелама за претрагу. Али ако није могуће имплементирати такве измене, IBAnalyst ће вам показати „лоше“ индексе на страним кључевима сваки пут када прегледате статистику.

Извештаји

Нема потребе да сваки пут прегледате цео извештај, уочавајући боју ћелија и читајући савете за нова упозорења. Директније и детаљније информације можете добити користећи функцију Препоруке у IBAnalyst-у. Само учитајте статистику и идите на мени Извештаји/Преглед препорука. Овај извештај пружа анализу корак по корак, укључујући детаљнија описна упозорења о принудном упису, интервалу чишћења, активности базе података, стању трансакција, величини странице базе података, чишћењу, страницама инвентара трансакција, фрагментованим табелама, табелама са много верзија записа, масовним брисањима/ажурирањима, дубоким индексима, индексима неповољним за оптимизатор, бескорисним индексима, па чак и празним табелама. Све ове информације и пратећи предлози се динамички креирају на основу учитане статистике.

Као пример излаза извештаја, погледајмо извештај генерисан за статистику базе података коју сте видели раније у овом чланку:

„Укупна величина страница инвентара трансакција (TIP) је велика - 94 килобајта или 23 странице. Read_committed трансакција користи глобални TIP, али snapshot трансакције праве сопствене копије TIP-а у меморији. Велика величина TIP-а може успорити перформансе. Покушајте да покренете чишћење ручно (gfix -sweep) да бисте смањили величину TIP-а.“

Ево још једног цитата из дела извештаја о табелама/индексима:

„Број табела са верзијама: 8. Велика количина верзија записа обично успорава перформансе. Ако у табели постоји много верзија записа, онда сакупљање смећа не ради, или записи не читају ниједним select упитом. Можете покушати select count(*) на тим табелама да бисте приморали сакупљање смећа, али то може потрајати дуго (ако постоји много верзија и нејединствених индекса) и може бити неуспешно ако постоји бар једна трансакција заинтересована за ове верзије.

Ево листе табела са односом верзија/запис већим од 3:


Табела	Записи	Верзије	Величина рец/вер
CLIENTS_PR	3388	10944	92%
DICT_PRICE	30	1992	45%
DOCS	9	2225	64%
N_PART	13835	72594	83%
REGISTR_NC	241	4085	56%
SKL_NC	1640	7736	170%
STAT_QUICK	17649	85062	110%
UO_LOCK	283	8490	144%

Резиме

IBAnalyst је непроцењив алат који помаже кориснику у обављању детаљне анализе статистике Firebird или InterBase базе података и идентификовању могућих проблема са базом података у погледу перформанси, одржавања и начина на који апликација интерагује са базом података. Он узима нејасну статистику базе података и приказује је на лак за разумевање, графички начин и аутоматски ће дати разумне предлоге о побољшању перформанси базе података и олакшавању одржавања базе података.

1 InterBase 7.5 и Firebird 1.5 поседују посебне функције које могу периодично да испразне несачуване странице ако је Forced Writes искључен.

2 Најстарија трансакција је иста као најстарија интересантна трансакција, поменута свуда. Gstat излаз не приказује ову трансакцију као „интересантну“.

3 Ен Харисон каже да је најстарија активна трансакција она која је била активна када је текућа најстарија активна трансакција започела. За апликације ово овде није велика разлика.