Въпроси за дистрибуция четат вече около 6000 души, а сайтът се посещава ежедневно от 100 души, предимно от България и Украйна. Въпреки, че според заявките за търсене и "чужди" посетителите се случва много. Основното нещо - това е почти сигурно целевата аудитория: разработчиците на приложения, администратори на бази данни, както и всичко, един или друг начин се интересуват от Oracle технологии и бази данни.
Чакам вашите предложения.
Как мога да променя маса. премести таблици?
Не може ли да обясни как операторът извършва алтер маса t_name ход за таблици. Това може да стане онлайн (онлайн), без да излизате (с опция nologging). Но данните Перин от една таблица пространство към друг? Имат ли сървърът генерира вмъкване отчети и предаване на данни чрез кеш буфер като по обичайния Поставянето му или има нещо като незабавното поставяне?
Натъкнах се на следния проблем, за който бих искал да се намери бърз начин да се реши:
Има размер маса от 2.5 GB. Искам да го прехвърли от пространството за таблици, от А до Б. Всички файлове а и б са разделени на групи и са в различни дискове. Тази таблица - независим. Искам да кажа, че той не е установен предпоставки и ограничения за интегритет.
Първият метод:
Вторият начин:
Ще има ли втори път да се работи по-бързо, отколкото на първата, в резултат на използването на директен вложка?
Какво soposob ще работи по-бързо, и защо? ако първият метод позволява паралелното? Булет значителна разлика в използването на сегмента на намаление на цените и пространство, за да се справи?
Отговор от Том Кайт
Действие ход в оперативен режим може да се извършва само на една маса, организирана от индекса (индекс организирана маса - ИОТ), но не и за обикновения маса, организирана като купчина.
Логично е да го направите:
Оператор променя маса т ход таблици б nologging; трансфер на маса (и влезете, ако тя е била зададена), а след това инсталира nologging атрибут.
Когато сте в движение да прехвърли SQL таблици не се използва. Не вложки не са изпълнени.
Този трансфер е добре, че всички индекси, привилегии и т.н. остават. Необходимо е само да се възстанови (но не и регенерира) кодове след трансфер.
Вторият метод може да работи по-бързо, ако използвате едновременно вложки (проверете дали използвате / * +. Не само / *. За да зададете оптимизатор съвети) Но за това трябва да се работи по-дълго. 2.5 GB за размера на масата аз не съм сигурен, че е си заслужава - това може да отнеме повече време, за да се разработят процедури за прехвърляне от самия пренос.
Прехвърляне на пространство за таблици с nologging на опцията
The Oracle Enterprise Edition 8.1.7.2 правя следното:
Аз не знам, тя работи с или без сеч, но след таблицата за прехвърляне в режим nologging не е преведена. И във версия Oracle 8.1.6 резултат на друг?
Отговор от Том Кайт
Е, сеч / nologging параметър има две значения, в зависимост от контекста.
В контекста на къде да го използвате, ще бъдете помолени да извърши прехвърлянето, без да излизате, ако обектът позволява работа без zhurnallizatsii.
Ако се изпълни "променя маса т nologging", променя сеч / nologging атрибут.
Както винаги, това ще ви помогне да се разбере по примера. Ние ще създадем една маса, да го плъзнете и да видите колко ремонтирам данни се генерира чрез използване на различни методи за трансфер:
Така че, има маса тест. Той първоначално е бил създаден в пространството на маса и Utils:
си режим сеч - YES (сеч е настроен). Сега нека видим колко ремонтирам данни вече генерирани на сесията, и освен тази стойност в променлива разширяване V на
Сега изпълни командата си. Тази команда може да бъде в руската формулиран по следния начин: "Преместете маса T в пространството за таблици на потребителите, както и от начина, по който, ако можете, без да излизате". По-специално, тази команда не казва: "Преместване на масата и промяна на режима на сеч."
Така ние виждаме, че генерира около 4 MB на ремонтирам данни - изглежда, че действието, всъщност, zhurnaliziruetsya. Това може да се потвърди, промяна сеч режим:
и след това се прехвърля на тази таблица:
Сега ние бяхме получили само 26 килобайта ремонтирам данни - достатъчно, за да запишете промените в речника на данни, но не променя прехвърлените единици. Ние са се преместили на обекта, без да излизате всички промени.
В действителност, ние открихме, че не може едновременно да изпълнява даден обект и да го променят по някакъв друг начин (тези опции са взаимно изключващи се - вие или движещи се обекти, или променяте по друг начин - в същото време не може да се направи)
Възможно ли е да се възстанови на работа, ако се използва nologging?
Ако има прекъсване на база данни и трябва да го възстанови след употреба nologging за прехвърляне, независимо дали това ще бъде възможно да се възстанови това действие. След възстановяването дали tavblitsa в оригиналната таблица пространство?
Отговор от Том Кайт
Това зависи от причината за провала и други условия.
Базата данни работи в noarchivelog режим. защото възстановяването е възможно само по време на последния пълен бекъп извършва в студен режим, помощ при срив, този въпрос не е от значение изобщо (това е защо ние трябва да работим в archivelog режим!).
Което означава "маса ogranizovannaya в купчина"?
Отговор от Том Кайт
В таблиците по-организирани като купчина
Маси, организирани под формата на купчини, се използват в приложения 99 (ако не и повече) на сто от случаите, въпреки че с течение на времето това може да се промени в резултат на по-интензивно използване на маси, организирани от индекса - всъщност за тези таблици е възможно също да се създадат допълнителни индекси. Маса, организирана в една купчина, по подразбиране се създава, когато Създаване на изявление на маса. Ако искате да създадете таблица на друг вид, това трябва да бъде ясно посочено в отчета за CREATE.
"Пиле" - класически структура от данни, учи в курсове за програмиране. Това е по същество голяма площ на място на диск или в паметта (в случая на таблица на база данни, разбира се, на диска), използвани по произволен начин. Те са поставени там, където има място за тях, а не в определен ред. Мнозина вярват, че данните ще бъдат получени от една маса в същия ред, в който да се запише, но организацията като купчина не е гарантирана. Всъщност, точно обратното е гарантирано: низ ще бъдат върнати в напълно непредсказуем начин. Много е лесно да се докаже. Нека създадем една маса, за да ми база данни в блока поставя едно цяло въже (използвам размер на блока от 8 KB). Не е необходимо да се създаде един пример за една линия в блока. Аз просто искам да се докаже, очаквани поредица от събития. Такова поведение няма да се осъществи за всички размери на таблици и бази данни от всякакъв размер на блока:
.
наличност списъци
Преместих се в нов LMTs маса, а след това се анализира масата. Чудя се защо NUM_FREELIST_BLOCKS колона = 0 dba_tables. Във всички таблици имат неизползвани единици, както и една единица - само няколко линии.
Отговор от Том Кайт
Тъй като блоковете, в които данните никога не е било, ще бъдат по-високи от максимално ниво, а не в списъците на празните места.
В списъците с наличие на блокове падне след употреба - ако те никога не са били използвани, а след това в списъка на празни места те няма.
Веднага след повторното създаване, както е в твоя случай, то е естествено, че списъкът на свободните места LITTLE блокове, ако изобщо, те са там. Това просто означава, че всички съществуващи информационни блокове "опаковани" - там вече не е възможно да се вмъкне редове. След смяна / изтриване на данни, някои блокове ще бъдат в списъка на свободните места.
Да разгледаме следния пример (таблици система се контролира в речника, а потребителите таблици - с местно управление):
Плътно опаковани маса - не се блокира в списъка на свободните места, все още.
И сега - има; ние добавихме блокове в списъка на свободното пространство, като изтриете някои редове.
Сега те имат отново - всички свободни блокове са над максималното ниво (HWM), а не в списъка на свободните места.
и тук отново там - на масата вече не е "опакован", защото, когато изтриете част от сайта освободен
Прехвърляне на таблици в 7.3.4 Parallel Server
Ние използваме Oracle 7.3.4 Parallel Server OS NCR SVR4 (на неформатиран дискове). I използва и втория подход е да се прехвърлят на масата на друга маса пространство, защото оператор 7.3.4 алтер маса ход таблици на. Направих така:
След това отново създам индекс на orgfoo на маса. Бих искал да знаете:
а) ли е това решение добре за версия 7.3.4? Намерих решението си на сайта, където се препоръчва:
- потребителското износ верига
- Изтриване на всички потребителски обекти
- Изберете привилегията неограничен потребителското tablspace
- Променете пространството за таблици по подразбиране за потребителя
- Внос на потребителски данни
Но аз искам да се движи само един голяма маса, и не всички от масите. След отстраняване на всички обекти, както аз да я импортирате в две различни маса пространство?
б) след като го преименувате на масата, независимо дали това е необходимо, за да пресъздаде всички гледни точки, преди пускането на програмата?
в) Да orgfoo маса (таблици EHISTDAT) отпуснати 250 MB. Тази информация имам от dba_data_files и dba_free_space преди да извадите orgfoo маса.
И когато по повод на маса EKATSDAT създаването tempfoo и премахване orgfoo маса. Имам следния резултат:
Брой степени и блокове в dba_extents на изгледа се различава. EHISTDAT на таблици освободени 250 MB, а пространството за таблици са отпуснати, не 250, а само 110 MB. Може ли да се обясни това? Смятате ли, че такива действия, полезни, за да запазите място на диска?
Отговор от Том Кайт
Начинът ви е доста приемливо. Можете да направите износ индивидуални шкафчета, а не целия кръг - тя също е хубаво, но техниката си е перфектен (освен ако пресъздайте всички ограничения, тригери, привилегии и т.н. - всичко това прави полезността EXP автоматично).
След смяна на имената не е необходимо да правите нищо на масата. Подаване да се грижи за себе си, както и съхранени процедури.
Що се отнася до различията "размери" - новосъздадената масата отново "опаковани". В резултат на това тя може да се окаже, че е "по-малко от". А какво да кажем за "програма, за да се спести място" - аз не мисля така. Няколко седмици / месеци на масата отново да нарасне до предишния си размер. Това е като, когато отида на диета - теглото намалява леко, но в крайна сметка той отново е увеличен на "комфорт". Редовен реорганизация на таблица:
а) тя не изглежда необходимо
б) не съм се препоръчва (тя е обща за да чуете "палачинка, част от данните са загубени", защото по време на реорганизацията на грешката)
в) Поставете диска "спаси" за няколко дни, и в крайна сметка по размер се увеличава отново с предишната стабилна ниво.
Неспазването например при преместване на масата с nologging на опцията
Какво се случва, ако не успея случая в хода на масата за трансфер с nologging опция? Ние няма да загубите данни? Това не е ли опасно?
Отговор от Том Кайт
Не, nologging засяга само възстановяване след медии недостатъчност, но не и след неуспех инстанция.
При прехвърляне на таблицата с таблицата на опция nologging се копира от сегмент постоянна във времето сегмент. В края на това действие, временно сегмента се превръща в DC - тогава Voto копирате и се превръща в реална маса.
Ако възникне повреда, например по време на прехвърлянето, SMON процес просто почистване на временна сегмент, и тя ще изглежда така, сякаш ние не докосвайте масата (непрекъснат сегмент остава на място).
Ако възникне повреда например след прехвърлянето - Всичко е наред, тъй като данните се записва директно на диск и да ги възстанови преди възстановяване на копието не е необходимо.
Ако след прехвърлянето на данни е променен, промяната записва и не успя - Тоде е добре, тъй като данните за ремонтирам за тази промяна са на разположение и те могат да бъдат възстановени.
Ако има прекъсване на диск, и след прехвърлянето на архивни файлове, които са били засегнати от действието на опция nologging - тогава да ", имаме проблем." Ето защо в производствена среда, има основание да се опция NOLOGGING не се използва, и ако ние го използвате:
- първо резервно копие на съоръжения;
- извършване на действие без сеч;
- отново, за да създадете резервно копие на обектите.
Така че, проблемите с инстанция на неуспех не възникнат!
Отговор от Том Кайт
Изпълнение DML отчети само ако действието се извършва "на линия" (променя индекс възстанови онлайн например, да промени цялата таблица онлайн -. Но само за маси, организирани на индекса).
В Oracle9i там dbms_redefinition пакет, за да пресъздаде в онлайн режим на повечето обекти (което ви позволява да извършвате ГСД по време на транспортните оператори).
Видях например трансфер на маса. Това вместо 4MB повторите данни (ако предаването е включена сеч) се генерира само 26 Kbytes.
Опитах се да направя същото, но не виждам разликата. Може ли да се каже, че правя грешно. Тук са моите резултати:
Както можете да видите, когато на масата се журнализирана, генерирани 54320 байта ремонтирам данни, без да влезете в - 53 908 байта. Дори повече от 412 байта.
Отговор от Том Кайт
Вие работите в noarchivelog режим.
По този начин на действие не е необходимо да се генерира ремонтирам - така че те се генерират, независимо от сеч / nologging.
Паралелното?
Така че, ако искате да се "движат" маса на друго пространство за таблици (например речник, успя да локално управлявани) ще бъде по-бързо, за да използвате INSERT / * + APPEND * /. сложи на масата в nologging режим. вместо да използвате ход (с nologging опция)?
Какво ще кажете за паралелно Oracle 8.1.6 СТАНДАРТ? Мога ли да използвам нещо като:
Екипът работи, но аз не знам как да се провери дали паралелното изпълнение.
Съветва, от гледна точка на само резултати, които е по-добре - Поставете с APPEND nologging или преместване nologging.
Отговор от Том Кайт
Паралелното е възможно само в областта на ЕЕ и PE. Вижте. В документацията
Така че, в паралелното SE разположение.
Но по някаква причина се стори за вас, че вложка / * + Добавяне на * / трябва да бъде по-добре?
Аз току-що се премества в режим на маса T nologging и да го премести:
По-лесно е, отколкото вложка се прикрепя към него. Тя не се губи привилегии и индекси.
(Poroverit че действието е паралелизирано, можете да подавате заявки px_processes на о $ в хода на извършване на действие)
Тествах и в двете посоки, но не и в SQL * Plus околната среда, така че е по-лесно да се извини, че не може просто да изрежете и поставите "цялата истина".
Аз създадох две пространства за таблици. Създадох маса базирани dba_objects и удвои че все още не се е явил в него
1,8 милиона линии.
350 Mbytes с размер блок 16 KB.
След това се преместих в таблицата в режим nologging (без паралелно).
Машината тест - двоен, с Oracle 8.1.6 ЕЕ и конвенционален диск (без RAID). При тестването на всеки тест, проведен в най-малко два пъти:
Ако е необходимо, ще повторя същите тестове в SQL * Plus околната среда, както и да копирате резултатите.
Така че, защо вмъкнете / * + добавете * / е по-бързо, отколкото в движение?
Данните са получени чрез повторно изпълнение на 200-350 Kbyte.
Отговор от Том Кайт
Бих казал, че разликата между 137 и 125 секунди (общо време за изпълнение) не е от съществено значение. 12 секунди от нищо казват - особено на компютър с някои други действия.
Но както pokazyvapet си същия тест, променя маса се движи паралелно 2 писти 2 пъти по-бързо (първи опит паралелното може да работи по-бавно, поради факта, че е необходимо да тече дете обработва PQ - както и стартирането на 4 процеси отне толкова много време, може да е било конфликти с достъпа до източника или целевия диск).
Не бих се направи въз основа на това заключение, че вложка добави по-бързо. Бих казал, че това е много по-трудно, по-малко удобни и обикновено погрешно.
Интересното е, че след като на масата е преместена, то индекси стане невалиден и трябва да бъде възстановен - а индексът е възстановен? На масата с новия ценности ROWID (мисля така) или съществуващ индекс (ROWID, която не може да се използва вече).
Отговор от Том Кайт
Моля, вижте таблицата, за да получите стойностите на ROWID.
Оригинален обсъждане на този въпрос може да се намери тук.
С най-добри пожелания,