Zwei Anmerkungen jedoch noch: Bei der 32bit-Clientinstallation genügt der Oracle Instant Client und nachdem beide ORACLE_HOME’s installiert sind, muss in der Registry der Wert der Systemvariable ORACLE_HOME geleert werden. Erst dann können sich VMware vCenter (64bit-Umgebung) und der Update Manager (32bit-Umgebung) gleichzeitig auf die Datenbank verbinden. Ist die Variable mit einem Wert belegt, funktioniert entweder nur die Verbindung zu vCenter oder die zum Update Manager.

Das Einrichten einer ORACLE 11gR1 Datenbank unter Windows Server 2oo8 64-Bit ist an und für sich kein Problem, es sei denn, die Sicherheitseinstellungen auf dem System sind extrem hoch eingestellt (z.B. wegen BSI-Vorgaben). Da kann es schonmal vorkommen, dass man unter dem Account, unter dem man installiert hat, selbst den Listener nicht mal mehr stoppen kann. Das Starten und die Statusabfrage funktioniert.

Damit man als – angeblicher – Eigentümer des Listeners diesen auch wieder stoppen kann, ist folgende Zeile in der listener.ora einzutragen:

SQLNET.AUTHENTICATION_SERVICES = NONE

Sollte diese Zeile in der listener.ora bereits vorhanden sein, muss lediglich der Wert in NONE geändert werden.

Normalerweise sollten Benutzerrechte auf Unterordner vererbt werden. Das dachte ich auch, bis ich die Datenbank auf dem System mit sehr hohen Sicherheitseinstellungen eingerichtet hatte. Danach gehörte “mir” nicht mal der Ordner mit den .dbf-Files. Da ich Adminrechte hatte, ließ sich das ändern…

Die erste Hürde ist genommen, die Datenbank ist installiert und man kann sich connecten. Zur nächsten Baustelle – der Installation von VMware vCenter Server: Der Installationanleitung ist zu entnehmen, dass VMware vCenter Server den 32-Bit-ODBC-Treiber von ORACLE nutzt; wir befinden uns aber auf einem 64-Bit-System. Unter Windows 2008 sind alle systemnahen 32-Bit-Dienste in dem Verzeichnis

%windir%\SysWOW64

zu finden, so auch die Datei odbcad32.exe. Da jedoch die 64-Bit-Version von ORACLE 11g installiert ist, ist der Treiber nicht an dieser Stelle zu finden, sondern in der Systemverwaltung, also in der Standardumgebung. Erstellt man eine ODBC-Verbindung regulär über die Systemverwaltung, wird diese später von der VMware-Setup-Routine nicht erkannt, stattdessen erscheint folgendes:

In einem Thread des Oracle-Forums steht, dass man die ORACLE Database Gateways installieren soll, damit der Treiber auch in der 32-Bit-Umgebung steht. Das kann ich leider nicht bestätigen. Erst die Installation des 32-Bit-Clients – bzw. davon nur die ODBC-Verbindung – brachte den gewünschten Erfolg.
Man musste nach der Client-Installation lediglich die Datenbank in die tnsnames.ora des Client-ORACLE_HOME eintragen und die ODBC-Verbindung unter %windir%\SysWOW64\odbcad32.exe einrichten, und das Setup von VMware vCenter Server konnte ohne weiteres fortgesetzt werden.

Da ist zum einen das SQL-Script in dem Beitrag von Hölschi bei killer-tomate.de. Er fragt damit die Index- und Tabellengrößen im eigenen User-Schema ab und stellt die Größen in MByte dar.

Etwas detaillierter ist das SQL-Script von Held Informatik (meine persönliche Meinung…). Es beschränkt sich auf explizit Tabellen und der DBA hat die Möglichkeit, die Tabellengrößen einzelner Schemata oder der Datenbank insgesamt abzufragen. Auch die Darstellung der Größe ist etwas benutzerfreundlicher.

Ja, was tun? Nennt man jetzt die allokierte Tablespace-Größe des Users, der ihm/ihr bekannt ist, oder nennt man nur den gegenwärtigen Daten-Füllgrad des Tablespaces? Oder geht man einen Schritt weiter und beziffert die Größe der Datenbank mit der Summe aller Datafiles? Mancher DBA fügt dieser Summe sogar die Größe der Tempfiles hinzu.

Was ist aber mit den Redologs und Controlfiles? Die gehören schließlich auch zur Datenbank! Die Größe der Datenbank in Bezug auf sämtliche Dateien, aus denen sie besteht – Datafiles, Tempfiles, Redologs und Controlfiles, lässt sich mit Hilfe einer kleinen PL/SQL Prozedur ermitteln.

set serveroutput on
set feedback off
declare
db_name varchar2(25);
alloc_database_size number;
used_database_size number;
alloc_datafile_size number;
used_datafile_size number;
alloc_tempfile_size number;
used_tempfile_size number;
redologfile_size number;
controlfile_size number;
begin
select db_unique_name into db_name from v$database;
select sum(bytes) data_file_size into alloc_datafile_size from dba_data_files;
select sum(bytes) temp_file_size into alloc_tempfile_size from dba_temp_files;
select sum(bytes_used) used_temp_file_size into used_tempfile_size from v$temp_space_header;
select sum(bytes) redo_log_size into redologfile_size from v$log;
select (a.bytes-b.bytes) bytes_used into used_datafile_size from (select sum(bytes) bytes from dba_data_files) a, (select sum(bytes) bytes from dba_free_space) b;
select (block_size * (1 + file_size_blks)) control_file_size into controlfile_size from v$controlfile where rownum = 1;
alloc_database_size := round((alloc_datafile_size + alloc_tempfile_size + redologfile_size + controlfile_size)/1024/1024/1024,3);
used_database_size := round((used_datafile_size + used_tempfile_size + redologfile_size + controlfile_size)/1024/1024/1024,3);
alloc_datafile_size := round(alloc_datafile_size/1024/1024/1024,3);
used_datafile_size := round(used_datafile_size/1024/1024/1024,3);
alloc_tempfile_size := round(alloc_tempfile_size/1024/1024/1024,3);
used_tempfile_size  := round(used_tempfile_size /1024/1024/1024,3);
redologfile_size := round(redologfile_size/1024/1024/1024,3);
controlfile_size := round(controlfile_size/1024/1024/1024,3);
dbms_output.put_line(‘Groesse der Datenbank ‘|| db_name);
dbms_output.put_line(‘—————————–’);
dbms_output.put_line(‘allokiert: ‘ || alloc_database_size || ‘ GB’);
dbms_output.put_line(‘genutzt:   ‘ || used_database_size || ‘ GB’);
dbms_output.put_line(‘—————————–’);
dbms_output.put_line(‘Details:’);
dbms_output.put_line(‘Groesse der Datafiles   : ‘ || alloc_datafile_size || ‘ GB’);
dbms_output.put_line(‘-> davon genutzt        : ‘ || used_datafile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Tempfiles   : ‘ || alloc_tempfile_size || ‘ GB’);
dbms_output.put_line(‘-> davon genutzt        : ‘ || used_tempfile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Redologfiles: ‘ || redologfile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Controlfiles: ‘ || controlfile_size || ‘ GB’);
end;
/

In der Prozedur wird sowohl die Größe der einzelnen Dateien als auch deren Füllgrad (bei Datafiles und Tempfiles) berücksichtigt. Selbstverständlich kann das Script dahin gehend erweitert werden, dass z.B. die Tablespaces einzeln aufgelistet werden. Sollte die Datenbank im Archivelog Mode gefahren werden (was für produktive Umgebungen zu empfehlen ist), können in der Prozedur auch die Archivelogs berücksichtigt werden.

Download:Note: There is a file embedded within this post, please visit this post to download the file.