Jellemzői a táblázatok használata által szervezett, a névsor - oracle - szoftverek

Érdekel, hogyan kell újra helyet az asztalon, szervezett egy index (Index szervezett táblázat - IOT) eltávolítása után jelentős számú sorok.

Míg a normál tábla eltávolítása után a sorok száma, azt újra az indexek az index blokkok nincsenek hiányosságok, mint tudjuk, ez egy üres helyre az indexek nem lehet újra felhasználni (szemben a blokkok asztalok, ahol a kihasználatlanság után újra hogyan PCTUSED küszöb blokk) leküzdeni.

Szóval, mit lehet tenni egy asztal által szervezett index, annak érdekében, hogy megakadályozzák a folyamatos növekedés, sőt eltávolítása után a sorok száma?

Válasz Tom Kyte

A válasz erre a kérdésre valóban nagyon érdekes - Oracle8i Release 8.1 lehetővé teszi, hogy két új intézkedéseket, amelyek egy érdekes választ:

• gyors újjáépítése indexek;
• transzfer asztalra.

Mivel a táblázat által szervezett index - ez csak egy index. Sőt, mi is újra az indexet át a „útközben” táblázatban (azaz, amíg van felüdítő felhasználó módosíthatja az adatokat a táblázatban.)

Most már csak eltávolítani mintegy fele a sorok a táblázatban. Mi eltávolítja „keresztül” sort.

Tehát a mi index sok törölt tételek (sem az egységek nem teljesen üres). Hogyan „tiszta”?

Itt van, amit kaptunk - minden „tisztítani”. Amint egy teszt, akkor hagyjuk nyitva többi ülés amíg a alter table mozog - csak hogy megbizonyosodjon arról, hogy a tábla áll rendelkezésre kérdések és valamennyi piaci DML.

Említetted a két módszer. Egyikük - operatív újjáépítése az index.

Próbáltam alkalmazni, de semmi sem történt.

Válasz Tom Kyte

Ez úgy történik, hogy az üzemeltető:

Változás elsődleges kulcs tábla által szervezett index

Ha, mondjuk, én szervezett index táblázat T oszlopok. b. c. d. ahol az oszlopok a, b képezik az elsődleges kulcsot.

Azt is meg kell adni egy elsődleges kulcs oszlopok a, b, c. Van nem változtat asztal nyilatkozatot. Lehetővé teszi, hogy módosítsa a táblázat által szervezett index, és adjunk hozzá egy másik oszlopban az összetett elsődleges kulcsot?

Válasz Tom Kyte

Az Oracle9i, akkor az online újra.

A 8i, akkor kell használni a Tábla létrehozása. mint válasszuk. . törölni a régit, és nevezze át az újat.

Ha, mondjuk, én szervezett index táblázat T oszlopok. b. c. d. De most az elsődleges kulcs oszlopok alkotnak. b. c. ebben a sorrendben.

Azt találtam, hogy a legtöbb lekérdezések használtam feltétele az oszlopok, c. Így hasznos összetett kulcs oszlopok a, b, c. Összehasonlítva az összetett kulcs oszlopokon, c?

Válasz Tom Kyte

Elsődleges kulcs - az elsődleges kulcs a fő jellemzője.

Míg a legtöbb hozzáférést kér a táblázat oszlopokon, c. Az elsődleges kulcs kell lennie oszlopokban a, c, b

Kérdés törekvés.

Felét kéri - a, c. a másik fele - a, b.

Ha létrehoz egy összetett elsődleges kulcs oszlopok a, b, c. Függetlenül attól, hogy fogják használni az összes ilyen lekérdezéseket? A, b kér egy kicsit több, mint a, c.

Próbáltam a szerveren fejlesztési táblát használ által szervezett index helyett a szokásos asztalnál, és nyert tkprof különbség elegendő volt, hogy igazolja egy ilyen megvalósítás éles kiszolgálón.

A rendszer osztályába tartozik 24x7, és a leállás minimalizálni kell.

Hogyan befagyasztására az említett táblázat? Hogy van-e az üzemeltető „ALTER TABLE <имя_таблицы> csak olvasható „- Nem találom azt a 8i vagy forrás tabllitsa be kell fagyasztani az üzemeltető create table, vagy választhat ...?

Bemegyek csúcsidőben, hogy tegye a következőket:

1. átnevezni az asztalra - további változások nem fordulnak elő
2. create table <исходная таблица> vagy választhat az

Megnéztem függően egyéb tárgyakat az asztalra, és nem találták őket. Az elsődleges kulcs a táblázat nem hivatkozik idegen kulcsok más asztalok, és maga a táblázat nem tartalmaz semmilyen idegen kulcsokat.

Válasz Tom Kyte

és a másik példányt.

Ezután az első menetben, törlés és átnevezés az új tábla.

A 8i, ha a kiválasztott kérés adatait a, b és c. a legvalószínűbb, hogy létre kell hozni az indexeket:

Külön-külön, a „c” oszlopban, mert az összes indexet az asztalon által szervezett index, így többek között az elsődleges kulcsot. Vegyük ezt a példát:

Látod, hogy a kérelem nem kizárólag az index? Mert értékeit nem kell utalni az asztalra - ez az index.

Függetlenül attól, hogy az index újbóli van szükség?

Miért kell újra létrehozni az indexeket. Maga ellen átépítés indexek. Itt a válasz:

Válasz Tom Kyte

Nem bánom, újra létrehozni minden.

I - szemben a hagyományos helyreállítási indexek egyszerűen azért, mert „mindenki tudja, hogy az utat megtenni.”

Én ellenzem az intézkedések végrehajtásának, amiről nem ismert, hogy:

• hogy a rendszer jobb,
• nem okoz káros hatásokat.

bitmap indexek (bitmap indexek) is szükség lehet, hogy újra, miután egy bizonyos számú DML utasításokat.

Saját szöveges index asktom helyszínen - Van, hogy időről időre, újra, miután jelentős adatváltozás (sőt, ez nagyon hasonlít a bitmap index).

Indexek alapján b * -fa - nem valószínű, hogy valaha is újra érdemes (hint :. Tudnivalók a COALESCE - biztosítja a legtöbb ugyanazokat az előnyöket, és a munka sokkal kevesebb).

Csináltam egy táblázatot által szervezett index használható, mint a legördülő listából:

Érdekel az alábbi:

1. Lényegében két indexek ugyanazon oszlop a táblázatban. Hatékonyan, és hogyan kell kezelni egy index?

2. megadásához explicit nevet a túlfolyó asztal (túlcsordulás)?

Azt is szeretném tudni, hogy a javaslatokat javítja a teljesítményt.

Válasz Tom Kyte

1) Ami azt illeti, ha csak az egyik index - a funkciókat, hogy már létrehozott. Egy másik „Index” - van, sőt, maga a táblázat.

2) túlfolyó szegmens ebben az esetben szükségtelen, és nem kívánatos. Sőt, azt mondanám, hogy ha szüksége van egy túlfolyó szegmenst, akkor valószínűleg nem kell egy szervezet az index táblázat (vannak persze kivételek).

Ha mindig keres egy string nagybetűs, akkor hozzon létre egy táblázatot:

és egyszerűen másolja be a nevét nagybetűvel nevét és display_yn.

Ebben az esetben kapsz:

• csak egy asztalon által szervezett index;
• nem félreérthető, mert most van az értéke „elsődleges kulcs” tábla egyaránt lehet „hello”, és a „Hello”.

A szerver talál egy sort egy táblában által szervezett index

Vajon az elsődleges kulcs értékét a kiszolgáló, hogy gyorsan megtalálja a táblázat sorai a szervezésében az index? Ő nem tartja a rowid. mint a szokásos index alapján b-tree? Meg tudná magyarázni, hogy mit mechanizmust használnak.

Válasz Tom Kyte

A tárolt „rowid”, de az egyetemes, nem egy fizikai. És ez valóban tartalmaz egy elsődleges kulcs értékét. Vegyük ezt a példát:

Látod, milyen nagy lehet rowid.

A kulcs index tartalmazza.

Ez azt jelenti, hogy megfelelően az oszlop index (másodlagos index) értéke a kulcs, az elsődleges kulcsot érték és rowid (logikai)?

Válasz Tom Kyte

Igen. Felhívjuk figyelmét, mint az alábbi példában egy hozzáférési az csak T_IDX index. de általában nem vonatkoznak az asztalra. Bár az index - csak az Y oszlopban.

Méret táblázat által szervezett index

Én részt vesz az átalakulás néhány „nagy, de sovány” táblákat a több mint 10.000 sor az index szervezett és úgy találták, hogy jelentősen javítja a teljesítményt.

Mit gondolsz, van értelme megszervezni az index táblázat kevesebb, mint 10.000 sor? Ez nem ad ez egy jelentős előnyt rendszeres asztal indexek?

Válasz Tom Kyte

Igen, természetesen. Ha keres egy kulcs csak 1/3 logikai IO lehet szükség. Ha egy ilyen keresést végeznek gyakran 100 sort a táblázatba vagy 10.000 - ez nem számít.

Összeolvadnak vagy MOVE ONLINE

1) Ha a használata ALTER iot_table COALESCE. és amikor - ALTER iot_table MOVE ONLINE. Vannak esetek, amikor a használata COALESCE indokolt?

2) Ha van egy index iot_table asztal és mi MOVE ONLINE. e újjáépíteni az index?

Válasz Tom Kyte

1) Használja összefolynak a „tömörítés” az asztal által szervezett index.

A következő lépés annak átadása. Ugyanakkor van egy komplett újbóli létrehozása, valamint annak szükségességét, hogy helyet a táblázat mérete.

2) egy index táblázatot által szervezett alapuló indexet elsődleges kulcsokat. Amikor át egy elsődleges kulcs érték nem változik, így nem kell újra létrehozni az indexeket.

Rendszeres táblaindexek kell újra létrehozni (megváltoztatja fizikai sor ID), és az indexek az asztalon által szervezett index - nem.

Index egy nagy blokk mérete

Ahogy az egyik indexbejegyzés nagyobb lehet, mint 4000 bájt egy blokk mérete 2 KB?

Válasz Tom Kyte

Úgy néz ki, mint egy hiba, hogy elfelejtettem, hogy ellenőrizze. Ha a tábla sorai, amelyek meghaladják a maximális méret, meg kellett kapnia:

ha alter lépés sikeres munkát, kapsz:

amikor megpróbál beilleszteni egy nagyon nagy húr.

Így nincs adat korrupció stb Nem történik - csak kimaradt vizsgálat előtt transzfer. Már fel egy hibát alapján az üzenet a következő teszt:

Hogyan érhetem el, hogy egy szabályos táblázat által szervezett index?

Szervezése index táblázat megfelelőnek tűnik az én esetemben. Van egy táblázat - 6 millió sor, a kezelések, amelyeknek mindig követi ugyanazt az indexet; táblázatban csak öt oszlopot és 3 létrehoz egy indexet, hogy a szervezet a táblázat az index úgy tűnik, a tökéletes megoldás. De van két kérdés.

Hogyan, hogy valóban „átszervezése” a táblázat az index? Ha létrehoz egy új táblát, és végre: helyezze be. select *. ha hatmillió sorok, ez a művelet véget ér előbb vagy utóbb sikerül (miután minden szegmensében a rollback lesz elfoglalva). Nincs egy érdekes módon megváltoztatni a szervezet az asztalra? És ha nem, ha exportálni szeretne egy táblázatot, törlöm, hozzon létre egy táblázatot az azonos nevű, de eltérő szervezet. Függetlenül attól, hogy az import a munka? Van-e ok (intenzív beépítés / módosítás.), Amelyben a szervezet nem szabad használni az index táblázat?

És még egy kérdés: Van-e lehetőség a partíciós tábla által szervezett index? Ez általában akkor van értelme?

Válasz Tom Kyte

Minden végződik jól, ha a méret rollback szegmensek összhangban intézkedéseket kell végrehajtani (az ég szerelmére, én gyakran 10 millió és több „széles” sorok dolgozik a laptop. A laptop!)

Akkor partíció egy táblázat által szervezett index, igen.

Igen, ennek van értelme (de 6 millió sor, egyébként, ez egy kicsit)

kiderül, hogy használják körülbelül annyi, mint egy blokkban a szegmensben rollback :) Aggódsz, hogy nem történik (mint archív napló módban van, akkor ezt a műveletet elvégezni a nologging módban. egyetértők DBA mentést az új adatok, mint például lehető leghamarabb, és ezzel megszünteti a problémát a magazin újra, hogy meg tudná képzelni erőltetett):

Használt és VISSZA volt egyben!

Tartomány megosztjuk által szervezett index táblázat tömörítés

A 9iR2 Van egy asztal 3 oszlopot, hozzávetőleg egymilliárd sorok, de még mindig gyorsan növekszik. Szeretném particionálni azt tartományban tömöríteni és megszervezi index.

Nem akarok túl sokat. -)

Én már létrehozott egy particionált tábla által szervezett index, és úgy néz ki, mint a teljesítmény (és nem csak) jelentősen, számos kritériumot, amely nem akarom abbahagyni.

Majd megbízhatóságának tesztelésére / sebesség és egyéb szempontok adattömörítés a táblázatban (a már szervezett a fent leírtak szerint), de a fő kérdés az, hogy egy ilyen megoldás (ha tesztelés hozam pozitív eredmények) stabil és alkalmas „ipari” kezelhető? Ie nincsenek ismert hibák „árnyalt” vagy más problémák válhat osuschestvennym akadály vagy jelentős veszélyt jelent a jövőben.

Válasz Tom Kyte

3 „szűk” oszlop = zamechtaelno táblázat által szervezett index

1,000,000,000 sorok = alkalmas jelölt a particionálás

Ha a kezdeti oszlopok sok ismétlődő értékeket, a tömörítés = nagyon rossz ötlet.

Nem tudom, hogy néhány „árnyalatok”, és a lehetséges problémákat, amelyek nem engedi csinálni.

Chtoy elégedett.

Köszönöm a választ, de azt szeretnénk, hogy győződjön meg arról, hogy helyesen írta le a helyzetet, mert ez elengedhetetlen ebben az esetben:

Szeretném használni szervezett az index tartományban megosztjuk és sűrített asztalok, primetrno mint a megállapított alábbi (I valahol szintaxis tömörítés) [By the way, kösz a tippet a „belépési oszlopot ismétlődő értékeket”]

Azt hittem egy pillanatra, ha jól értem, hogy indokolja a particionált vagy szervezett az index az asztalra, de szeretnék valamit, a másik, és a tömörítés, de aggódik a lehetőségét, adatvesztés, stb hosszú távon. Van egy memória - az autó, hogy a tömörítés során nem zavar, bár meg kell tesztelni. Me inkább az adatok a korrupció, stb Plusz ha készül TRUNCATE (véletlenül tette a járatos, mint levágni rész) - Van, hogy újra létrehozni az egész táblát, vagy csak ez a rendezett index rész :-)

Vajon a forgatókönyv bemutatott eredményeket egy komoly cég sikeresen tesztelték, és minden gond nélkül az adminisztráció?

(Kérdés a 10g kidobják, mert Tom nem válaszolt, amíg - .. Megjegyzés VK)

Válasz Tom Kyte

Nem azt írtam, hogy a táblázat által szervezett index, amely megosztjuk, és esetleg tömörített, lehet nagyon megközelítés.

Tudok a használata nagy particionált táblák által szervezett index (kb tömörítés nem vagyok biztos, hogy ez általában figyelmen kívül hagyják), és sikeresen működik.