database cloning

Da das Thema <cloning> offenbar häufiger angeschnitten wird, hier ein Link auf die passenden Threads bei AskTom:

• http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:634671569269
• http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:318216852435

(die wiederum MetaLink-Artikel enthalten; die verwendete Version ist jeweils 8i, aber mit 9 sollte es ähnlich funktionieren)

Nachtrag 19.10.2012: die Links verweisen dieser Tage ins Nirvana, aber man findet beim Herrn Kyte natürlich immer noch viel Relevantes zu diesem Thema, z.B. hier.

MVs für Postgres

Ausnahmsweise mal etwas zu Postgres. Der folgende Link beschreibt sehr detailliert, wie man in Postgres Materialisierte Views anlegen kann: http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html.

Tablespaceerweiterung

Die Vergrößerung einer Datendatei eines Tablespaces kann auf mehreren Wegen erfolgen:

alter database datafile 'pfadangabe_für_die_datendatei' autoextend on maxsize 1000M;

Dabei haben die Optionen folgende Wirkung:

• autoextend on: schaltet die automatische file-Erweiterung ein
• maxsize: ist (man ahnt es schon) die maximale Größe des Datenfiles.

Wer die automatische Erweiterung nicht mag, kann eine Datei bei Bedarf manuell vergrößern:

alter database datafile 'pfadangabe_für_die_datendatei' resize 1000M;

(was allerdings abhängig von der Größe etwas dauern kann)

Vorraussetzung für die Operation sind die erforderlichen Systemprivilegien (die beispielsweise in der DBA-Rolle enthalten sind). Bedenken sollte man bei autoextend, dass auch genügend Platz dafür auf der Platte vorhanden sein muss (damit die Platte nicht vollständig gefüllt wird). Darüber hinaus gibt es dann noch OS- und Blocksize-abhängige Limits für die Größe der Datendateien.

Alternativ kann man auch mehrere data files zum Tablespace hinzufügen (was ab einer gewissen Größe der files allein schon aus Gründen der Handhabbarkeit des Backups sinnvoller sein dürfte als der Einsatz eines sehr großen files).

Materialized View: Fast Refresh on Commit

Hier mal eine minimale Definition einer MV mit Fast Refresh on Commit:

create table test1 (a number);

alter table test1 add constraint test1pk primary key (a);

CREATE MATERIALIZED VIEW LOG ON test1 WITH PRIMARY KEY, ROWID INCLUDING NEW VALUES;

create materialized view test1_mv 
refresh fast on commit 
as 
select * 
  from test1;

select * 
  from test1;

no rows selected

select * 
  from test1_mv;

no rows selected

insert into test1 values (1);

1 row created.

select * 
  from test1;

A
----------
1

1 row selected.

select * 
  from test1_mv;

no rows selected

commit;

Commit complete.

select * 
  from test1_mv;

A
----------
1

1 row selected.

Beim Commit werden die Änderungen an die MV propagiert. Erforderlich sind ein Primary Key (da könnte man natürlich auch einen synthetischen Key verwenden) und ein View Log, das alle Änderungen der Basis-Tabelle protokolliert.    

Länge von Long-Spalten anzeigen

Vom Datentyp LONG rät Oracle ziemlich entschieden ab und empfiehlt stattdessen den Einsatz von LOBs. Für LONG-Spalten gibt es meines Wissens keine einfache Möglichkeit, die Länge zu bestimmen. Allerdings gibt es eine Funktion TO_LOB, mit der man LONGs in LOBs umwandeln kann, aber leider kann diese Funktion nur innerhalb einer Unterabfrage für ein INSERT verwendet werden:

create table test (a long);
insert into test values ('bllllllllllllllllllllllaaaaaaaaaaaaaaaaa');
select to_lob(a) 
  from test;

ERROR at line 1: ORA-00932: inconsistent datatypes: expected - got LONG

create table test2 (b clob);
insert into test2(b)
select to_lob(a) 
  from test;

select dbms_lob.getlength(b) from test2;

DBMS_LOB.GETLENGTH(B)
---------------------
40

Zur Bestimmung der Länge bräuchte man also eine Hilfstabelle, in die man den LONG-Wert einfügen könnte, um seine Länge dann mittels dbms_lob.getlength zu ermitteln - was natürlich eher umständlich ist.

Alternativ kann man die Länge auch in einem PL/SQL-Block bestimmen:

DECLARE
long_var LONG;
BEGIN
SELECT a 
  INTO long_var
  FROM test;

DBMS_OUTPUT.PUT_LINE('LOB_LENGTH:' || LENGTH(long_var));
end;
/
LOB_LENGTH:40

PL/SQL-Prozedur erfolgreich abgeschlossen.

Aber eine Funktion, die aus einem SQL-Statement heraus aufgerufen werden kann, wird daraus leider nicht, weil solche Funktionen keine LONGs als Parameter annehmen.