Frank's Oracle Blog

Nach 9 Monaten Projektarbeit auf C-Level geht's ab nächstem Jahr wieder an neue alte Aufgaben. In diesem Sinne: Allen ein erfolgreiches Jahr 2008!

ungeprüft mal übernommen: Lt. ISO/DIN liegt der 4. Jan IMMER in KW01 eines Jahres. Anhand dieses Musters sollten sich alle Kalenderwochen ableiten lassen. Wenn 04.Jan ein Montag -> dann 03.Jan in KW 53 Wenn 04.Jan ein Sonntag -> dann ist der 29.12. ein Montag und gehört bereits zur KW 01.

Enabling Automatic Shared Memory Management WICHTIG - diese Einstellung nur in Version 10gR2 einsetzen! Wer Mut hat bitte mal mit 9i testen ;-) ALTER SYSTEM SET SGA_MAX_SIZE = 650M scope=spfile; ALTER SYSTEM SET SGA_TARGET = 650M scope=both; ALTER SYSTEM SET SHARED_POOL_SIZE = 0 scope=both; ALTER SYSTEM SET LARGE_POOL_SIZE = 0 scope=both; ALTER SYSTEM SET JAVA_POOL_SIZE = 0 scope=both; ALTER SYSTEM SET DB_CACHE_SIZE = 0 scope=both; ALTER SYSTEM SET STREAMS_POOL_SIZE = 0 scope=both;

gefunden zum Thema PGA: Link: http://www.pythian.com/documents/Working_with_Automatic_PGA.ppt Link: http://www.quest-pipelines.com/newsletter-v5/0304_A.htm PGA-Tuning: 1) show parameter pga_aggregate_target 2) select name,value from v$sysstat where name like 'workarea executions%'; 3) select * from v$pgastat; 4) select round(pga_target_for_estimate/1024/1024) as target_size_MB, bytes_processed, estd_extra_bytes_rw as est_rw_extra_bytes, estd_pga_cache_hit_percentage as est_hit_pct, estd_overalloc_count as est_overalloc from v$pga_target_advice; PGA-Bedarf aller aktueller Prozesse: SELECT ROUND (pga_alloc_mem / 1024 / 1024, 1) AS alloc_mb, ROUND (pga_used_mem / 1024 / 1024, 1) AS used_mb, ROUND (pga_max_mem / 1024 / 1024, 1) AS max_mb, pid, spid, serial#, program, traceid, background, pga_freeable_mem FROM v$process ORDER BY alloc_mb DESC unter UNIX/Linux Platzbedarf prüfen: pmap -xs

Eine sehr gute Zusammenfassung zum Statspack hab ich gefunden am 30.01.2007 bei MuniqSoft unter http://www.muniqsoft.de/tipps/dba/dba_allgemein.htm (mit eigenen Ergänzungen/Anpassungen) STATSPACK Um die Effizienz bzw. Verfügbarkeit einer Datenbank zu überwachen, oder um bereits vorhandene Ressourcenengpässe zu lokalisieren, stellt Oracle ab dem Release 8.1.6 ein sehr zuverlässiges Tool zur Statistiksammlung zur Verfügung. Mit STATSPACK können Statistiken über sämtliche Bereiche der Datenbank erstellt werden. Installieren von STATSPACK Nachdem das Skript "spcreate.sql" (vor Release 8.1.7 => "statscre.sql") , nach dem Prinzip von UTLB/ESTAT, Tabellen zum Speichern von den Snapshotwerten anlegt, sollte vor der Installation ein separater Tablespace angelegt werden der min. 180 MB groß ist (wegen Fragmentierung nicht System Tablespace verwenden). Skript in SQL*PLUS (nicht im Server Manager oder SQL*Worksheet) als SYS oder INTERNAL aufrufen.

Um sich an die ASM-Instanz wie an eine "normale" Datenbank verbinden zu können, ist eine Erweiterung der lokalen TNSNAMES.ORA notwendig: Bsp: DB04ASM.SCHWAB.DE = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = +ASM) (UR=A) ) )

Auf dem Zielsystem 1. root: Kopieren der DataProtector Software auf den Server (beide CD's !) 2. root: Installation der DataProtector Software (tar -zxvf .tar.gz) cd /LOCAL_INSTALL ./omnisetup.sh -source /opt/oracle/install/DP55/ -server backup2 -install da,oracle8 wobei: - source - Quellverzeichnis für Installation - server – DNS-Name des Backupservers - install – zu installierende Optionen - hier: o da – Disk Agent o oracle8 – Oracle Integration Hinweis: Die Installation geht nach /etc/opt/omni/... - Config-Dateien /opt/omni/... - Basisinstall /car/opt/omni/... - Logdateien (DP5.5.: /usr/omni/...) bei Problemen: o nur ./omnisetup.sh aufrufen und interaktiv die Module installieren o Cell_Server mit ./omnisetup.sh –server backup bekannt machen o manuell Datei cell_server im Verzeichnis /usr/omni/config/client erstellen: Inhalt: DNS-Name des DataProtector-Cell-Servers (z.B. dpserver) 3. oracle: (Oracle 8i/9i/10g) Einbindung in RMAN durch LINK · ALLE Daten