Cure d; бази данни за отслабване, коя диета да изберете

cure

В тази статия ще се заемем с тема, о! колко чувствителни и твърде често пренебрегвани от издателите на софтуерни пакети и други „домашни“ приложения прочистване на данни.

Внимавайте, говорим за прочистване, тоест за пълно изкореняване на данни, а не за архивиране, което е съвсем различна техника, макар и допълваща, но управлявана от много точни правила, които определят напълно различен формат от този на данните за произход, независим от всяко техническо ограничение. Но да се върнем към любимата ни тема ПРОЧИСТВАНЕ данни, както често сте виждали, виждате как вашите скъпи бази данни нарастват възмутително, без да има процедура или лечение, които могат да олекотят тези данни, които остаряват с времето и до които не се извършва повече достъп нито в четене, нито в писмена форма, а от друга ръка, които замърсяват масите, които рискуват значително да влошат представянето. Така че малко лекарство за отслабване не би било лукс да си възвърнете втора младост и да зачитате каноните на красотата, които заливат някои от списанията, въпреки че се съмнявам, че базата данни ще предизвика такава лудост ... Ефектът е много по-малко привлекателен, давам ви ...

И така, към кого ще се обърнем, за да намерим това чудодейно лекарство, което ще ни накара да загубим няколко размера за минимум време? Но разбира се на дежурния диетолог, нашия скъп DBA, който в крайна сметка се смее по-малко зад екрана си.

Анализ на наднорменото тегло

Преди да диагностицираме коя диета е най-ефективна, първо трябва да проучим естеството на наднорменото тегло, с което се сблъскваме и да определим какви данни заслужава тази суха диета. Като цяло вече имаме представа за данните, които нарастват над водата или по-скоро с течение на времето, като фактури, поръчки, потребление, билети за комуникация, финансови транзакции ... . Сега остава да идентифицираме таблиците, върху които са концентрирани тези пълни данни, да, но тогава кой подход да се възприеме:

Критерий за отслабване

Тъй като това са данни, които нарастват с течение на времето, единственият релевантен критерий, разбира се, е дата, която задължително трябва да съответства функционално на значим акт на заявлението (вземане на поръчки, потребление, комуникация, транзакция, фактуриране ...). Сега всичко, което трябва да направите, е да валидирате този критерий с проучванията или мениджърите на приложения и да определите с колко ще отрежете този излишен обем от данните ... С други думи, на по-тривиален език "намалете мазнините". Този период на съхранение ще ни позволи да усъвършенстваме и разкроим силуета на базата данни според нашите желания.

Правилната диета за отслабване

Сега просто трябва да приложим нашето лечебно лечение според нашите възможности и средства.

Драстичната диета

За по-добро състояние и при условие, че имаме опцията за разделяне (която между другото все още си струва теглото в фъстъците) и че в допълнение към всички таблици, за щастие имате известния критерий за дата, тогава решението е намерено да се използва опцията за разделяне чрез интервал или 'разделяне на диапазон' .

С версията на Oracle 11g тази опция е подобрена, така че вече не е задължително да се създават дялове предварително, защото те се генерират автоматично веднага щом трябва да се вмъкне нов ред в дял, който все още не съществува.

Както винаги има някои ограничения при използването на този тип разделяне на интервали.

  • Една колона не може да представлява критерий за разделяне и тази колона трябва да бъде от тип DATE или NUMBER
  • Разделянето на интервали не е разрешено за таблици, организирани в IOT индекси

Дълбочината на интервала на разделяне може да бъде ограничена до деня, седмицата, месеца, тримесечието .... от следните функции: ИНТЕРВАЛ (NUMTODSINTERVAL (1, 'ден')), ИНТЕРВАЛ (NUMTODSINTERVAL (7, 'ден')), ИНТЕРВАЛ (NUMTOYMINTERVAL (1, 'месец')), ИНТЕРВАЛ (NUMTOYMINTERVAL (3, 'месец') ))) ... . Тъй като името на дяловете се генерира автоматично според вътрешните конвенции на Oracle, препоръчително е да ги преименувате според вашите собствени стандарти.

Така че лечението за отслабване ще се извърши чрез просто изтриване на дяла с помощта на командата DROP, разбира се, спазвайки последователността на референтните ограничения. (първо таблиците дъщеря, след това таблиците майка).

Силно ограничение на тази команда DROP PARTITION остава фактът, че всички индекси са локални, тоест те се отнасят само и директно към един дял на таблицата, в обратния случай индексите ще бъдат обезсилени и ще трябва да бъдат възстановени което изисква спиране на услугата за приложения и все още засяга наличността на базата данни. Остава трънливият случай на първични индекси, които се отнасят до цялата таблица, така че те стават локални, наложително е да се добави критерият за разделяне в ключовата дефиниция на тези първични индекси.