На явните и скрити курсори, размерът на степен и разстоянието

Том Кайт: На явните и скрити курсори,
степен размер и комплексни диапазони
(В Изрично, размер и комплекс. С Том Кайт)

Нашият експерт отговаря на въпроси за курсори, степен и разстояние.

Въпрос: Вярно ли е, че тъй като базата данни Oracle7 Release 7.3, неявни курсори са оптимизирани и не изпълняват двойно вземане на проби? Също така, защо следващата имплицитно курсора по-бързо, показани по-долу изрично курсора, ако таблицата T разполага с показалец върху колона X, докато в противен случай изрично курсора работи по-бързо?

Отговор: Скритият курсора:

Ще започна с кратко определение, че всеки разбира, какви са явни и неявни курсори.

Като цяло, имплицитно курсора - този курсор, че програмист "очевидно" не се рекламират, не се отвори, да не се избира от него и го затваря; Тези операции са косвени. Така, в примера по-горе, заявката SELECT X В Y - имплицитно курсор. За него не съществува определение за "курсора cursor_name е.". Във втория пример, от друга страна, показва, класически изрично курсора. Програмист изрично декларира, тя се отваря, изберете от нея и тя се затваря.

Така че, наистина, неявни курсори в PL / SQL по-бързо от изрични курсори, и те бързо, преди освобождаването на базата данни Oracle7 Release 7.3. Всъщност, аз имам един набор от тестове, което показва, че това наистина е така в базата данни Oracle7 Release 7.1 (виж тези тестове. В asktom.oracle.com/

tkyte / ivse.html). Причината, поради която неявните курсори по-бързо (като имплицитни курсори курсора цикли за и неявни курсори в изявленията SELECT INTO), се крие във факта, че в този случай, PL / SQL машина се изисква да се тълкува и изпълнява много по-малко от кода си. Като цяло, колкото по-голям PL / SQL кода, можете да "скрие", толкова по-бързо той ще работи. За имплицитно курсора, показано по-горе, е необходим един ред PL / SQL код; за изрично курсора отнема най-малко три реда код, и ако го направите на "правилната" всъщност вземат шест реда код. Вие изрично код не извършва цялата работа имплицитно курсора, който удостоверява, че със сигурност ще се получи един и само един ред. Вие изрично код не е много от това, което трябва да направите. За точно сравнение на вашите два примера за курсори вашето изрично код трябва да има повече редове:

Ако беше вашето изрично курсора, вие ще откриете, че изричното курсора бавно във всички случаи, дори и в твоя пример с индекса или никакъв индекс.

Аз създадох една маса с голям брой блокове; това се прави чрез задаване на параметри PCTFREE 99, която запазва пространство блокове 99 на сто за последващи актуализации блокове ( "пространство"). Така че, въпреки че количеството на данните, в малка масичка, самата таблица е доста голям. В допълнение, поставя в таблица стойностите 1, 2, 3 до 29 264 до голяма степен се намират в ред. Така znachenieX = 1 е в "първи" блок масата и стойността X = 29 000 - достатъчно близо до последния блок на масата.

Това обяснява поведението на курсора: SELECT INTO проверки отчет на дружеството за втория ред, докато вашето изрично курсора не го направи. Ако сравняваме ябълки с ябълки - или да направите втори ясно проба, или да добавите предикат "ROWNUM = 1" на оператора SELECT INTO - ще откриете, че и двете курсори изпълняват една и съща сума на работа.

Въпрос: В нашата нова молба ние проектирахме база данни и да се създаде модел на данните. Ние дори зададете размера на маси и възможности за съхранение, определени за всяка маса. Но сега ни специалисти администриране на бази данни ни казва, че те ще ни даде три пространства за таблици: TS_small (таблица пространство е малък) от същата степен размера на 160 KB, TS_med (таблица пространство е средно голям) с един и същ размер степен до 5 MB и TS_large (таблици голям размер) с един и същ размер степен, равна на 160 MB. Те ни казват, че е необходимо да се създаде маси, размерът на които е по-малко от 5 MB в TS_small на таблици, размер маса ще бъде по-малко от 160 MB, TS_med и маси, размерът на които ще бъде повече от 160 MB, TS_large. В допълнение, те не искат да използваме никакви параметри за съхранение на ниво таблица. Те казват, че същото следва да бъде за индексите. Той не изглежда разумно за мен, защото една маса с прогнозна големина от 120 MB, трябва да бъде поставен в пространство за таблици TS_med, а това ще отнеме 24 степен! администратори на бази данни твърдят, че многобройни тестове са показали, че този дизайн осигурява най-добри резултати и да се предотврати фрагментирането. Моят въпрос е: те са прави? Аз съм притеснен за обектите с голям брой степен.

A: Ами, тя изглежда така, сякаш те са били четене на уебсайт "Попитайте Том" (asktom.oracle.com) и дискусионни групи по интереси в интернет и открих една добра препоръка. С поглед към номерата им, виждам, че една маса до 5GB ще има 32 или по-малко степен. Като се има предвид, че стотици (или дори повече) на степен няма да се отрази на работата извърши манипулация на данни езикови отчети (ГСД), бих казал, че те свърши отлична работа.

И двете си предположения са верни: раздробяването на пространството за таблици няма да бъде възможно, но ефективността ще е оптимално. Нека да разгледаме всяко твърдение.

Фактът, че фрагментирането е невъзможно, трябва да проверите. Таблица пространство, контролирано от речника на данни (речник управлявана таблици), фрагментиран поради различни по големина степен. Таблица пространство се управлява от речника на данни, че може да има хиляди степен, безплатен и се използва, всяка от които може да са с различен размер. Сега, вие започвате да се унищожи и създаване на обекти в пространството за таблици и в път, когато са се формирали в него голям брой "дупки" с различна големина (свободно пространство). Така че, можете да проверите пространството за таблици се контролира от речник на данните, както и за определяне на размера на свободното място в него да се намери 500 MB свободно. Но когато се опитате да създадете таблица с размера на първоначалната степен, равна на нивото на 40 MB, получите съобщение за грешка - не е възможно да се разпределят на първата степен. Как е възможно това да се случи? Имате 500 МБ свободно, нали? Да, добре, но за съжаление, това са 500 MB в различни степени, всяка от които е с размер по-малък от 40 MB! Така че, имате голям неизползваем пространство - масата ви пространство е фрагментирана. Сега, помислете LMTs (локално успя таблици) степен с еднакъв размер. Тук всяка степен е със същия размер като на всички останали размерите, без изключение. Ако установите, че имате 500 MB свободно, мога да ви уверя, че ще бъдете в състояние да се разпределят на нова степен в пространството за таблици, като всеки свободен степен по дефиниция може да се използва за вашия обект.

tkyte / extents.html и asktom.oracle.com/

tkyte / extents2.html. всяка от които съдържа един доста дълъг разговор на тази тема. Тридесет и две степени за вашите обекти - това е отлично, като цяло няма да има въздействие върху производителността. В действителност, тъй като LMTs много по-ефективни в разпределяне на пространството, от пространството за таблици, контролирана от речник на данните, както и използването им за увеличаване на производителността, а не обратното.

Въпрос: Използвам DBMS_JOB пакет и искате да планирате задачата на всеки 15 минути от понеделник до петък, като се започне в 6:00 часа сутринта до 18:00. Как може да се направи? Не мога да се изчисли интервала предава на пакета.

A: Ами, за да се изчисли комплекс пакет интервали DBMS_JOB, Обичам да използвам новите (като се започне с Oracle8i Release 2), дело на оператора. Например, следното изявление CASE връща правилния слот за вашите очила:

изявление CASE осигурява по-голяма гъвкавост при генерирането на комплексна стойност, която Ви е необходима. За съжаление, DBMS_JOB пакет ви позволява да използвате само тези интервали, продължителността на които не надвишава 200 знака, а дори и да "вмъкне" е показано на горното твърдение, установите, че дължината му е приблизително равна на най-малко 300 символа. Така че, вие не можете да го използвате директно в пакета на повикване DBMS_JOB. Моето решение е следният: или аз щях да създаде представа NEXT_DATE, операторът SELECT * FROM next_date върна следващата задача план, или щях да реализира по-горе изявление в PL / SQL функция, която връща дата. Ако аз бях на идеята, пакета ми предизвикателство DBMS_JOB може да изглежда така: /

Въпрос: Имаме няколко маси разделени от време (на финансовата година). Какво ще препоръчате като най-добрият подход за достъп до исторически данни в "само за четене", както и достъп до текущите данни - в режим на "четене и запис"?

Отговор: В действителност, това е съвсем проста, за да се постигне. Пространството на маса може да е в "само за четене" или в "четене и запис". Ако използвате отделно пространство таблица за всеки дял (или поне да се запази историческото секцията в отделна таблица пространство от сегашните), ще трябва да го направи достъпно само на "само за четене", можете просто да изпълни ALTER TABLESPACE <имя табличного пространства> ПРОЧЕТЕТЕ САМО. Крайните потребители не могат да променят пространството на маса, а в действителност, можете да спестите значително количество време, прекарано на резервата, защото вие ще трябва да създадете резервно копие веднъж (освен ако не го поставите в режим на "четене и запис" и променя това, в този случай, вие естествено трябва да отново да създадете резервно копие).

Всъщност, вие дори може да се движи в пространството маса на медиите е само за четене, като компактдискове, предотвратяване на възможността за тази модификация.

Въпрос: Може ли да обясните какво рекурсивни повиквания, db блок получава, и т.н.

Сървърът Oracle поддържа таблици, използвани за вътрешни операции. Ако сървърът Oracle искате да промените таблицата, която се генерира от SQL-оператор на системата, което от своя страна генерира рекурсивни повиквания.

Накратко, рекурсивни на повикванията са основно SQL-изявления, направени от името на вашата SQL-декларация. Например, ако ви се налага да се направи разбор анализа на заявка, може да се наложи да изпълнява някои други искания за информация от речника на данните. Това би било рекурсивно повикване. управление на пространството, правила за инспекция за контрол на достъпа, наричат PL / SQL процедури от SQL-оператори - всичко това води до прилагането на рекурсивни повиквания.

DB Блок Gets (база данни прочетете блокове). Броят на блокове, получени в текущия режим.

Прочетете документацията Oracle9i:
Tuning Guide Oracle9i база данни и справочник
otn.oracle.com/docs/products/oracle9i/
doc_library / release2 / server.920 / a96533 / autotrac.htm # 14931

ASK Том
asktom.oracle.com
Том Кайт - вицепрезидент на Oracle правителство, образованието, здравеопазването и група - отговори на вашите най-трудните въпроси, свързани с технологиите на Oracle база данни. Акценти от този форум се появяват в тази графа.

УЧЕБНИТЕ курсори:
asktom.oracle.com/

Последователно Gets (последователно четене) Колко пъти да блокират искания за изпълнение операции последователно четене.

По принцип, това се равнява на общата размера на вашия резултат сет.

Байтове, получени чрез SQL * Нето от Client (байтове, получени от клиент на SQL * Net). Общият брой байтове, получени от клиент по мрежата.

По принцип, това е - размерът на заявката ви, във формата, в която се предава по мрежата

SQL * Net двупосочни пътувания до / от клиент (взаимен обмен на SQL * Нето от клиента). Общият брой на мрежовите съобщения, изпратени или получени от клиента.

По принцип, това е - броят на взаимодействието ви с сървъра, за да получите отговор. След като сте в SQL * Plus ще се увеличи стойността на променлива ARRAYSIZE на системата, ще видите, че този брой е за SELECT отчети, които се връщат много редове, намалени (по-малко възли, тъй като всеки екстракт N линии - взаимен обмен). Когато се намали ARRAYSIZE стойност, ще видите, че този брой се увеличава.

Сорт (памет) (сортиране памет). Броят на видове, които са били изпълнени изцяло в RAM и не изискват писмена форма на диск.

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

Сорт (диск) (сортиране на диск). Броят на операциите за сортиране, които изискват най-малко един запис на диска. Сортът, които изискват диск IO интензивно консумират ресурси. Опитайте се да се увеличи стойността на SORT_AREA_SIZE на инициализация параметър.
Редове преработени (редове обработени). Общият брой на редовете върна Изберете вашия оператор или променен от INSERT оператор, актуализирате или изтриете.