Distribuțiile de distribuție sunt citite de aproximativ 6000 de persoane, iar site-ul este vizitat zilnic de până la 100 de persoane, în principal din Rusia și Ucraina. Deși, în funcție de cererile de căutare și de vizitatorii "străini", există multe. Principalul lucru este că este aproape o sută de clienți vizați: dezvoltatori de aplicații, administratori de baze de date și, în general, toți cei interesați de tehnologiile și bazele de date Oracle într-un fel sau altul.
Aștept sugestiile dvs.
Cum se execută tabelul de modificare. muta spațiul de tabel?
Puteți clarifica modul în care este implementat operatorul de modificare a tabelului t_name pentru a muta spațiul de tabelă. Acest lucru se poate face online (online) și fără înregistrare (cu opțiunea de nologging). Dar cum migrează datele de la un spațiu de tabel la altul? Serverul trebuie să creeze instrucțiuni de inserare și să treacă date prin cache-ul tampon ca în cazul inserției obișnuite sau să apară ceva asemănător unei inserții directe?
Am intrat în următoarea problemă, pentru care aș dori să găsesc o soluție rapidă:
Există un tabel de 2,5 GB. Vreau să-l mut din spațiul de masă a la b. Toate fișierele a și b sunt împărțite în benzi și sunt pe discuri diferite. Acest tabel este independent. Adică, nu există nicio declanșare și constrângeri de integritate pentru aceasta.
Primul mod:
Al doilea mod:
Va funcționa cel de-al doilea mod mai rapid decât primul, utilizând o inserare directă?
Ce comparație va funcționa mai repede și de ce? Prima metodă permite paralelizarea? Există o diferență semnificativă în utilizarea segmentului de redirecționare și a spațiului pentru sortare?
Răspunsul lui Tom Kite
Acțiunea de mutare în modul online poate fi efectuată NUMAI pentru o tabelă organizată cu index (IOT), dar nu pentru un tabel regulat organizat ca un heap.
Are sens să faci acest lucru:
Operatorul de tabelă de schimbare nu se deplasează în tabel; va muta tabela (cu logare dacă a fost instalată), apoi setați atributul nologging.
Când executați deplasarea, tabela SQL nu este utilizată pentru migrare. Nu sunt executate inserturi.
Acest transfer este bun pentru că toți indiciile, privilegiile și așa mai departe. rămân. Este necesară numai reconstruirea (dar nu re-crearea) a indicilor după transfer.
Al doilea mod poate funcționa mai repede dacă utilizați inserții paralele (asigurați-vă că optimizatorul utilizează / * + în loc de doar / *). Dar pentru a face acest lucru va trebui să lucrați mai mult. Pentru un tabel de 2,5 GB, nu sunt sigur dacă merită - este posibil să dureze mai mult timp pentru a dezvolta o procedură de migrare decât pentru a migra singură.
Mutarea spațiului de masă cu opțiunea de nologizare
În Oracle Enterprise Edition 8.1.7.2, fac următoarele:
Nu știu dacă funcționează cu sau fără jurnalizare, dar după mutarea mesei în modul nologging nu este tradus. Și în versiunea de Oracle 8.1.6 rezultatul este diferit?
Răspunsul lui Tom Kite
Parametrul logging / nologging are două sensuri, în funcție de context.
În contextul în care l-ați folosit mai sus, ați cerut portului să efectueze fără a fi înregistrat dacă obiectul permite lucrul fără înregistrare.
Dacă executați instrucțiunea "alter table nologging", atributul logging / nologging se modifică.
Ca întotdeauna, pentru a înțelege acest lucru va fi un exemplu. Vom crea tabelul, îl vom muta și vom vedea cât vor fi generate datele de execuție atunci când se vor folosi diferite metode de transfer:
Deci, există o masă de testare. Acesta a fost inițial creat în spațiul de masă UTILS și:
modul său de înregistrare este YES (înregistrarea este setată). Acum, să vedem câte date re-executate au generat deja sesiunea și să stocheze această valoare în variabila substituită V
Și acum, să-ți îndeplinim comanda. Această comandă poate fi formulată în limba rusă după cum urmează: "Deplasați tabelul T în spațiul de tabele al utilizatorilor și, apropo, dacă este posibil, FĂRĂ JOURNALISM". În special, această comandă nu spune: "Mutați masa și schimbați modul de înregistrare".
Deci, vedem că au fost generate aproximativ 4MB de date de re-executare - se pare că acțiunea este de fapt înregistrată. Acest lucru poate fi confirmat prin modificarea modului de înregistrare:
și din nou deplasând această masă:
Acum am generat doar 26 KB de date de re-execuție - acest lucru este suficient pentru a înregistra modificările în dicționarul de date, dar nu pentru modificările blocurilor transferate. Am mutat obiectul fără să înregistrăm toate modificările.
De fapt, am aflat că nu puteți transfera simultan un obiect și nu îl puteți schimba în nici un alt mod (aceste opțiuni se exclud reciproc - fie purtați obiectul, fie schimbați-l într-un alt mod - nu puteți să îl faceți în același timp)
Pot recupera acțiunea dacă se utilizează nologging?
Dacă baza de date se blochează și trebuie să o restabiliți după ce ați folosit pentru a migra, puteți restabili această acțiune. Și după recuperare, va masa în spațiul tabelului original?
Răspunsul lui Tom Kite
Depinde de cauza eșecului și de alte circumstanțe.
În baza de date care rulează în modul noarchivelog. deoarece aceasta poate fi restaurată numai în momentul ultimei backup-uri complete executate în modul rece, dacă suportul media nu reușește, această întrebare nu este deloc relevantă (prin urmare, este necesar să lucrați în modul archivelog!).
Ce înseamnă "masă, delimitată ca o grămadă"?
Răspunsul lui Tom Kite
Tabele organizate ca o grămadă
Tabelele organizate ca o grămadă sunt folosite de aplicații în 99 (dacă nu mai mult) procent din cazuri, deși acest lucru se poate schimba odată cu utilizarea mai intensă a tabelelor organizate de index, deoarece puteți crea indexuri suplimentare folosind astfel de tabele. Un tabel organizat ca un heap este creat implicit când se execută instrucțiunea CREATE TABLE. Dacă doriți să creați un alt tip de tabel, trebuie să îl specificați explicit în instrucțiunea CREATE.
"Heap" este o structură clasică de date studiată în cursuri de programare. Aceasta este în esență o zonă vastă de spațiu pe disc sau în memorie (în cazul unei tabele de baze de date, desigur, pe un disc), folosită arbitrar. Datele sunt plasate acolo unde există un loc pentru ei, și nu într-o anumită ordine. Mulți cred că datele vor fi obținute din tabel în aceeași ordine în care a fost înregistrată acolo, dar nu este garantată atunci când este organizată ca o grămadă. De fapt, inversul este garantat: liniile se vor întoarce într-o ordine absolut imprevizibilă. Acest lucru este foarte ușor de demonstrat. Să creăm o astfel de tabelă, astfel încât în baza mea de date din bloc să fie plasată o linie completă (folosesc blocuri de 8 KB). Nu este necesar să creați un exemplu cu o singură linie într-un bloc. Vreau doar să demonstrez o succesiune previzibilă de evenimente. Acest comportament va fi observat pentru tabele de orice dimensiune și în baze de date cu orice dimensiune de bloc:
.
Listele locurilor disponibile
Am mutat mesele într-un nou spațiu de tabel gestionat local, apoi am analizat tabelele. Mă întreb de ce coloana NUM_FREELIST_BLOCKS = 0 în dba_tables. În toate mesele există blocuri neutilizate, iar într-un bloc doar câteva linii.
Răspunsul lui Tom Kite
Deoarece blocurile în care NICIODATĂ nu aveați date, vor fi mai mari decât marcajul maxim, și nu în lista locurilor disponibile.
În lista locurilor disponibile, blocurile cad după utilizare - dacă nu au fost folosite niciodată, în lista locurilor disponibile nu vor exista.
Imediat după re-creație, ca și în cazul dvs., este firesc ca lista locurilor disponibile să fie mică, dacă există deloc. Aceasta înseamnă că toate blocurile de date existente sunt "împachetate" - nu mai pot introduce rânduri. După modificarea / ștergerea datelor, în lista locurilor disponibile vor apărea câteva blocuri.
Luați în considerare exemplul următor (sistemul de spațiu de tabelă este gestionat de dicționar și spațiul de tabele al utilizatorilor este gestionat local):
Tabel masiv ambalat - nu există blocuri în lista locurilor disponibile încă.
Și acum - este; Am adăugat blocuri în lista locurilor disponibile prin ștergerea unor rânduri.
Acum nu sunt acolo din nou - toate blocurile libere sunt deasupra marcajului maxim (HWM) și nu în lista locurilor disponibile.
dar a apărut din nou - masa nu mai este "împachetată", deoarece atunci când sa șters o parte a site-ului a fost eliberată
Transferarea tabelelor în 7.3.4 Server paralel
Utilizăm Oracle 7.3.4 Parallel Server în NCR SVR4 (pe discuri neformate). De asemenea, am folosit a doua abordare pentru a muta tabelele în alte spații de tabelă, deoarece în versiunea 7.3.4 tabelul alter muta operatorul tablespace. Am facut acest lucru:
Apoi am creat din nou indicii pe tabela orgfoo. Aș vrea să știu:
a) Este o soluție bună pentru versiunea 7.3.4? Am găsit soluția pe site-ul unde se recomandă:
- Exportă schema utilizatorilor
- Ștergeți toate obiectele utilizatorului
- Selectați tablspace privilegiu nelimitat de la utilizator
- Modificați spațiul de tabelă implicit pentru utilizator
- Importați date de utilizator
Dar vreau să transfer doar o masă mare, nu toate mesele. După ștergerea tuturor obiectelor, cum pot importa date în două spații de tabelă diferite?
b) După redenumirea tabelului, trebuie să re-creați toate vizualizările înainte de a rula aplicația?
c) Pentru tabela orgfoo (în spațiul de tabelă EHISTDAT) sunt alocate 250 MB. Am primit aceste informații din dba_data_files și dba_free_space înainte de a șterge tabela orgfoo.
Și când vi se solicită după crearea tabelului tempfoo în EKATSDAT și înlăturarea tabelului orgfoo. Am următorul rezultat:
Numărul de extensii și blocuri din vizualizarea dba_extents este, de asemenea, diferit. În spațiul de tabelă EHISTDAT, 250 MB au fost eliberate, iar în spațiul tabelă au fost alocate nu 250, ci doar 110 MB. Ai putea să explici asta? Considerați că astfel de acțiuni sunt utile pentru salvarea spațiului pe disc?
Răspunsul lui Tom Kite
Metoda dvs. este destul de acceptabilă. Puteți face tabele individuale de export, în loc de întregul circuit - este, de asemenea, frumos, dar tehnica este perfectă (cu excepția cazului în re-crea toate constrângerile, declanșează, privilegii, etc - toate acestea fac automat utilitarul EXP).
După redenumirea tabelului, nu trebuie să faceți nimic. Reprezentările proprii vor fi luate în considerare, precum și procedurile stocate.
În ceea ce privește diferența dintre "dimensiuni" - tabelul nou creat este nou "ambalat". Ca urmare, ar putea fi "mai puțin". Dar ceea ce înseamnă "utilitatea pentru salvarea spațiului" - nu cred. După câteva săptămâni / luni, masa va crește până la dimensiunea anterioară. Acest lucru este ca atunci când stați pe o dietă - greutatea scade ușor, dar în cele din urmă crește din nou la "confortabil". Reorganizarea regulată a tabelelor:
a) nu mi se pare necesar
b) Nu sunt recomandat (adesea auziți "pancake, unele date sunt pierdute" din cauza unor erori în cursul reorganizării)
c) spațiul de disc "salvează" pentru câteva zile, iar în timp dimensiunea crește din nou la nivelul stabil anterior.
O instanță a eșuat la mutarea unui tabel cu opțiunea de nologizare
Ce se întâmplă dacă instanța nu reușește în timpul migrării tabelului cu opțiunea de nologging? Nu vom pierde datele? Nu e periculos?
Răspunsul lui Tom Kite
Nu, nologgingul afectează numai recuperarea de la un MASK, dar nu după un eșec de instanță.
Când mutați o masă cu opțiunea nologging, masa este copiată din segmentul permanent în segmentul TIME. La sfârșitul acestei acțiuni, segmentul temporar este transformat într-unul permanent - atunci copia devine o masă reală.
Dacă apare o defecțiune exemplu, în timpul transferului, procesul de SMON curata doar în sus segmentul temporar, si va arata ca si cum nu atinge masa (segment continuu rămâne în vigoare).
Dacă instanța nu reușește după migrare, totul este bine, deoarece datele au fost scrise direct pe disc și nu este necesar să le restaurați atunci când restaurați instanța.
Dacă, după transfer, o parte din date a fost modificată, modificarea este corectă și a apărut o eroare - totul este bine, deoarece datele re-executate pentru aceste modificări sunt disponibile și pot fi restabilite.
Dacă după transferul și UP al fișierelor de backup care au fost afectate de acțiune cu opțiunea nologging, va apărea DISK DISC - atunci da, "avem probleme". De aceea, în mediul de producție există motive pentru opțiunea NOGGING să nu folosească și, dacă se folosește, să:
- creați mai întâi o copie de rezervă a obiectelor;
- efectuați o acțiune fără înregistrare;
- creați din nou o copie de siguranță a obiectelor.
Deci, problemele cu eșecul instanței nu apar deloc!
Răspunsul lui Tom Kite
Puteți executa instrucțiunile JDD numai dacă acțiunea este efectuată "online" (modificați indexul reconstruiți online, de exemplu, modificați tabelul muta online - dar numai pentru tabele organizate de index).
În Oracle9i, există un pachet numit dbms_redefinition pentru a recrea cele mai multe obiecte online (ceea ce vă permite să efectuați operatori NMD în timpul migrării).
Am văzut exemplul tău de a muta o masă. În el, în loc de 4 MB de date re-executate (dacă jurnalizarea a fost activată în timpul migrării), au fost generate doar 26 KB.
Am încercat să fac același lucru, dar nu am văzut diferența. Îmi poți spune ce greșesc. Iată rezultatele mele:
După cum puteți vedea, atunci când a fost înregistrată masa, s-au generat 54320 octeți de date de re-execuție, în 53908 octeți fără înregistrare. Chiar mai mult cu 412 octeți.
Răspunsul lui Tom Kite
Lucrați în modul noarchivelog.
În acest mod, nu este nevoie să generați date re-executate pentru această acțiune - acestea nu sunt generate, indiferent de setarea înregistrării / nologging-ului.
Paralelizare?
Deci, dacă vrei să „muta“ un tabel într-un alt spațiu tabelă (de exemplu, un dicționar reușit să local gestionat) va fi mai rapid pentru a utiliza INSERT / * + ADAUGARE * /. Mutați masa la nologging. mai degrabă decât folosind mișcare (cu opțiunea nologging)?
Și cum rămâne cu paralelizarea în Oracle 8.1.6 STANDARD? Pot folosi ceva de genul:
Echipa funcționează, dar nu știu cum să verific dacă a existat o paralelizare în execuție.
Recomandă, numai în termeni de performanță, care este mai bine - INSCRIȚI cu APPEND nologging sau muta nologging.
Răspunsul lui Tom Kite
Paralelizarea este posibilă numai în EE și PE. Consultați documentația
Deci, în SE, paralelizarea nu este disponibilă.
Dar de ce credeți că inserați / * + append * / ar trebui să fie mai bine?
Aș transfera pur și simplu tabelul T în modul nologging și îl transfer:
Acest lucru este mai ușor decât inserați adăugați. fără a pierde privilegii și indici.
(Verificați dacă acțiunea este paralelizată executând interogarea la v px px_processes în timpul executării acțiunii)
Am testat ambele metode, dar nu în mediul SQL * Plus, așa că îmi pare rău că nu pot să taie și să lipesc "întregul adevăr".
Am creat două mese de masă. Am creat un tabel bazat pe dba_objects și l-am dublat până când a fost găsit
1,8 milioane de linii.
350 MB cu o dimensiune de bloc de 16 KB.
Apoi am pus masa în mod nologging (fără paralelizare).
Mașina de testare este dual-procesor, cu Oracle 8.1.6 EE și discuri convenționale (fără RAID). În timpul testării, fiecare test a fost efectuat de cel puțin două ori:
Dacă este necesar, voi repeta aceleași teste în mediul SQL * Plus și copiați rezultatele.
Deci, de ce nu introduceți / * + append * / rulați mai repede decât mutați?
Datele re-executate au fost generate de la 200 la 350 KB.
Răspunsul lui Tom Kite
Aș spune că diferența dintre 137 și 125 secunde (timpul total de plumb) nu este semnificativă. 12 secunde despre tot ce nu spun - mai ales pe computerul care efectuează alte acțiuni.
Dar, după cum pokazyvapet același test de dvs., să modifice tabelul muta paralel 2 ruleaza de 2 ori mai rapid (prima paralelizare incercare ar putea rula mai lent din cauza faptului că a fost necesar pentru a rula copil procese PQ - precum și lansarea 4 procese a durat atât de mult timp posibil să fi fost intră în conflict cu accesul la sursă sau discul țintă).
Nu aș putea concluziona, pe această bază, că insertul atașat funcționează mai repede. Aș spune că este mult mai complicat, mai puțin convenabil și, în general, greșit.
Interesant, din moment ce tabelul a fost mutat, indicele său a devenit invalid și trebuie să fie reconstruit - și cum se reface indexul? Pe masă cu noile valori rowid (cred eu) sau pe indicele existent (rowid în care nu mai puteți folosi).
Răspunsul lui Tom Kite
Trebuie să consultați tabelul pentru a obține valori răsfrânte.
Discuția inițială a acestei probleme poate fi găsită aici.
Cu cele mai bune urări,
Trimiteți-le prietenilor: