Den
tablespace design er et resultat av et rekke undersøkelser i forretningslogikk
av applikasjoner, databasetyper av data, måte på å aksessere databaseressurser og målinger av ytelse. Målet var både å minske responstid
for applikasjonsbrukere, forbedre
resursbruk og redusere backup tid.
Hovedprinsipper
er:
-
alle applikasjonene klassifiseres og fordeles mest mulig etter
tilsvarende separate
FAG-tablespaces
-
tabeller og deres indekser , LOB segmenter, LOB av ORDSYS’s typer og
LOB av SDO typer ligger i separate tablespaces (LOB-indekser bygges av oracle
og ligger sammem med LOB segmenter )
-
conext indekser (tabeller) liger i et separat tablespace TEXT_INDEX
-
data som ikke endres er plassert i separate arkive tablespaces (og
ligger på en separat partisjon
ora_ro/USDPROD)
-
siden alle ONLINE tablespaces er under versjon 9i Local Managed, en
trenger ikke lenge storage parametre som initila/next osv; alle LM tablespaces
er autoextandable og har autoallocation for data extents
Tablespace
design vises fram i følgende tabell:
|
Fag området |
FAG_DATA (LM) |
FAG_DATA_ARKIV (DD) |
FAG_INDEX (LM) |
FAG _LOB (LM) |
FAG_LOB_ARKIV (LM) |
FAG_LOBORD FAG_MDLOB (LM) |
FAG_LOBORD_ARKIV/TRANSIT (LM) |
TEXT_INDEX (LM) |
|
ARK |
ARK_DATA |
|
ARK_INDEX |
ARK_LOB ARK_LOB2 |
ARK_LOB_ARKIV |
|
|
TEXT_INDEX |
|
ARK (før - GJENSTAND) |
ARK_DATA2 |
|
ARK_INDEX2 |
|
|
|
|
- “ - |
|
FELLES |
FELLES_DATA |
|
FELLES_INDEX |
FELLES_LOB |
|
FELLES_LOBORD |
FELLES_LOBORD_TRANSIT *) |
|
|
FELLES2 |
FELLES_DATA2 |
|
FELLES_INDEX2 |
FELLES_LOB2 |
|
|
|
- ” - |
|
HISTORIE |
HISTORIE_DATA |
|
HISTORIE_INDEX |
HISTORIE _LOB |
|
|
|
- “ - |
|
KART |
KART_DATA2 |
|
KART_INDEX |
KART_LOB |
|
KART_MDLOB |
|
- ” - |
|
KUNSTHISTORIE |
KUNSTHISTORIE_DATA |
|
KUNSTHISTORIE_INDEX |
KUNSTHISTORIE _LOB |
|
|
|
- “ - |
|
LEKS |
LEKS_DATA |
LEKS_DATA_ARKIV |
LEKS_INDEX |
LEKS_LOB (DD)
LEKS_LOB2 |
LEKS_LOB_ARKIV LEKS_LOB_ARKIV2 |
|
|
- “ - |
|
LEKS (før – TAGGER) |
LEKS_DATA2 |
|
LEKS_INDEX2 |
|
|
|
|
|
|
LEKS_VH (varehus) |
LEKS_VH_DATA |
|
LEKS_VH_INDEX |
LEKS_VH_LOB |
|
|
|
|
|
LITT |
LITT_DATA |
|
LITT_INDEX |
|
|
|
|
- “ - |
|
NAMN |
NAMN_DATA |
NAMN_DATA_ARKIV
|
NAMN_INDEX |
NAMN_LOB
|
NAMN_LOB_ARKIV
|
|
|
- “
- |
|
NATHIST |
NATHIST_DATA |
|
NATHIST_INDEX |
|
|
|
|
- “ - |
|
RYDD |
RYDD_DATA |
|
RYDD_INDEKS |
|
|
|
|
- “ - |
|
SPRAKRAD |
SPRAKRAD_DATA |
|
SPRAKRAD_INDEX |
|
|
|
|
- “ - |
|
STAD |
STAD_DATA |
STAD_DATA_ARKIV |
STAD_INDEX |
|
|
|
|
- “ - |
|
USERS |
USERS |
|
|
|
|
|
|
- “ - |
|
UTV |
UTV |
|
|
|
|
|
|
- “ - |
*) Tablespace FELLES_LOBORD_TRANSIT skulle brukes til inloading av images til databasen fra klient. Denne er autoextandable og har uniform data extent størrelse på 1M. I dag ble det tatt i bruk annen logikk som har bedre yttelse/hastighet: images overføres til inger via http/ftp protokoler, processeres under OS og kun imporeters/exporteres til USDPROD for å bli liggende som BFILEs med tilsvarende pekkere i tabeller. Mer detaliert er procedyren beskrevet i et dokument om interMedia objekter processing.
**) FAG_.._ARKIV områder er READ_ONLY tablespaces, en del av dem er Data Dictionary fremdeles. Disse skal reorganiseres når neste gang tabeller skal arkiveres