Oraklet http://www.oraklet.no Systemutvikling, drift, opplæring og rådgivning innen Oracle, Linux og Unix Tue, 16 Mar 2010 07:23:22 +0000 en hourly 1 http://wordpress.org/?v=abc Recovery Manager tips http://www.oraklet.no/2010/03/recovery-manager-tips/ http://www.oraklet.no/2010/03/recovery-manager-tips/#comments Tue, 16 Mar 2010 07:22:57 +0000 ingemar http://www.oraklet.no/?p=92 De fleste benytter Recovery Manager (rman) til å ta sikkerhetskopi av datafiler. Men rman kan også brukes til å flytte datafiler. Fordelen med det er at du har et godt sikkerhetsnett som beskytter deg og omgivelsen mot de store feilene.

Å flytte en datafile fra A til B er ikke noe problem, men hva hvis filnavnet inneholder ny linje eller noen andre sære tegn som kom dit av mistak?

Her vises et eksempel med en datafil i tablespace USERS som må flyttes.

Begynn med å sjekke hvilket filnummer tablespacen har og ta den offline.

 
z00u074:DR1R> sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Ti Mar 16 07:59:16 2010

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production

11g SYS@DR1R SQL> SELECT file_id, file_name
                                FROM dba_data_files
                                WHERE tablespace_name = 'USERS';

   FILE_ID FILE_NAME
---------- ------------------------------------------------------------
         8 /u04/oradata/DR1R/DR1R_users_
            01.dbf

11g SYS@DR1R SQL> ALTER TABLESPACE users OFFLINE;

Tablespace altered.

Datafil 8 skal flyttes, det gjør vi i rman.

 
z00u074:DR1R> rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Ti Mar 16 07:41:25 2010

connected to target database: DR1R (DBID=1942219211)

RMAN> COPY DATAFILE 8 to '/u04/oradata/DR1R/DR1R_users_01.dbf';

Starting backup at 16/03/2010 07:55:29

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile copy

input datafile file number=00008 name=/u04/oradata/DR1R/DR1R_users_
01.dbf

output file name=/u04/oradata/DR1R/DR1R_users_01.dbf tag=TAG20100316T075530 RECID=1 STAMP=713778931

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01

Finished backup at 16/03/2010 07:55:31

RMAN> LIST COPY LIKE '%users%';

specification does not match any archived log in the recovery catalog

List of Datafile Copies

=======================
Key     File S Completion Time     Ckp SCN    Ckp Time
------- ---- - ------------------- ---------- -------------------
1       8    A 16/03/2010 07:55:31 72709346997 16/03/2010 07:42:09

        Name: /u04/oradata/DR1R/DR1R_users_01.dbf

        Tag: TAG20100316T075530

RMAN> SWITCH DATAFILE 8 TO COPY;

datafile 8 switched to datafile copy "/u04/oradata/DR1R/DR1R_users_01.dbf"

RMAN> LIST COPY LIKE '%users%';

specification does not match any archived log in the recovery catalog

List of Datafile Copies

=======================

Key     File S Completion Time     Ckp SCN    Ckp Time
------- ---- - ------------------- ---------- -------------------
2       8    A 16/03/2010 07:56:01 72709346997 16/03/2010 07:42:09

        Name: /u04/oradata/DR1R/DR1R_users_
01.dbf

        Tag: TAG20091126T103852

Dermed er datafilen flyttet på en trygg og hurtig måte! Da gjenstår det å rydde opp, sjekk først at filen er på riktig sted i SQL*PLus.

 
11g SYS@DR1R SQL> SELECT file_id, file_name
                                FROM dba_data_files
                                WHERE tablespace_name = 'USERS';

   FILE_ID FILE_NAME
---------- ------------------------------------------------------------
         8 /u03/oradata/DR1R/DR1R_users_01.dbf

11g SYS@DR1R SQL> ALTER TABLESPACE users ONLINE;

Tablespace altered.

Fjern filen fra disken ved hjelp av rman.

 
RMAN> DELETE COPY LIKE '%users%';

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=513 device type=DISK

specification does not match any archived log in the recovery catalog

List of Datafile Copies

=======================

Key     File S Completion Time     Ckp SCN    Ckp Time
------- ---- - ------------------- ---------- -------------------
2       8    A 16/03/2010 07:56:01 72709346997 16/03/2010 07:42:09

        Name: /u04/oradata/DR1R/DR1R_users_
01.dbf

        Tag: TAG20091126T103852

Do you really want to delete the above objects (enter YES or NO)? YES

deleted datafile copy
datafile copy file name=/u04/oradata/DR1R/DR1R_users_
01.dbf RECID=2 STAMP=713778961
Deleted 1 object

]]> http://www.oraklet.no/2010/03/recovery-manager-tips/feed/ 0 Forenkle arbeidsdagen med rlwrap http://www.oraklet.no/2009/02/rlwrap/ http://www.oraklet.no/2009/02/rlwrap/#comments Tue, 10 Feb 2009 19:53:29 +0000 ingemar http://www.oraklet.no/?p=55 rlwrap. I usually wrap this program around all command based programs where I would like to use the arrows keys for easy editing.]]> Et av mine favorittprogram er rlwrap. Det programmet “pakker” jeg inn i andre programmer hvor jeg ønsker at pil-tastene skal anvendes for enkel redigering av teksten.

Hvis du arbeider på Ubuntu Linux finnes pakken ferdig kompilert, da er det bare å laste ned programmet:

 
oracle@ubuntu: ~ $ sudo apt-get install rlwrap
...


For de fleste andre Linux og Unix varianter må du først søke på Google etter rlwrap og laste ned kildekoden.

 
[oracle@linux tmp]$ tar xvzf rlwrap-0.30.tar.gz
rlwrap-0.30/
rlwrap-0.30/completions/
rlwrap-0.30/completions/ftp
...

[oracle@linux tmp]$ cd rlwrap-0.30
/tmp/rlwrap-0.30

[oracle@linux rlwrap-0.30]$ ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk

...

config.status: creating distribution/rlwrap.spec
config.status: creating config.h
config.status: executing depfiles commands

Now do:
make (or gmake)  to build rlwrap
make check       for instructions how to test it
make install     to install it

[oracle@linux rlwrap-0.30]$ make
make  all-recursive
make[1]: Entering directory `/tmp/rlwrap-0.30'
Making all in doc
/tmp/rlwrap-0.30/doc
make[2]: Entering directory `/tmp/rlwrap-0.30/doc'
sed -e 's#@DATADIR@#/usr/local/share#'  rlwrap.man > rlwrap.1
make[2]: Leaving directory `/tmp/rlwrap-0.30/doc'
Making all in src

[oracle@linux rlwrap-0.30]$ sudo make install
Password: ######
Making install in doc
/tmp/rlwrap-0.30/doc
make[1]: Entering directory `/tmp/rlwrap-0.30/doc'
make[2]: Entering directory `/tmp/rlwrap-0.30/doc'
make[2]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/share/man/man1" || /bin/mkdir -p "/usr/local/share/man/man1"
/usr/bin/install -c -m 644 './rlwrap.1' '/usr/local/share/man/man1/rlwrap.1'
make[2]: Leaving directory `/tmp/rlwrap-0.30/doc'
make[1]: Leaving directory `/tmp/rlwrap-0.30/doc'
Making install in src
/tmp/rlwrap-0.30/src
make[1]: Entering directory `/tmp/rlwrap-0.30/src'
make[2]: Entering directory `/tmp/rlwrap-0.30/src'
test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin"
/usr/bin/install -c 'rlwrap' '/usr/local/bin/rlwrap'
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/tmp/rlwrap-0.30/src'
make[1]: Leaving directory `/tmp/rlwrap-0.30/src'
make[1]: Entering directory `/tmp/rlwrap-0.30'
make[2]: Entering directory `/tmp/rlwrap-0.30'
make[2]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/share/rlwrap" || /bin/mkdir -p "/usr/local/share/rlwrap"
/usr/bin/install -c -m 644 'completions/ftp' '/usr/local/share/rlwrap/ftp'
/usr/bin/install -c -m 644 'completions/testclient' '/usr/local/share/rlwrap/testclient'
/usr/bin/install -c -m 644 'completions/coqtop' '/usr/local/share/rlwrap/coqtop'
make[2]: Leaving directory `/tmp/rlwrap-0.30'
make[1]: Leaving directory `/tmp/rlwrap-0.30'

[oracle@linux rlwrap-0.30]$ which rlwrap
/usr/local/bin/rlwrap

Muligens må du laste ned fler biblioteker for å få rlwrap til å kompilere.

 
[oracle@linux tmp]$ tar xvzf readline-5.2.tar.gz
readline-5.2/
readline-5.2/doc/
readline-5.2/doc/Makefile.in

...

[oracle@linux readline-5.2]$ cd readline-5.2
/tmp/readline-5.2

[oracle@linux readline-5.2]$  ./configure
[oracle@linux readline-5.2]$ make
[oracle@linux readline-5.2]$ sudo make install
[oracle@linux readline-5.2]$ sudo ldconfig

Legg inn noen alias i for eksempel .bashrc så er rlwrap inkludert i de programmene du bruker hver dag.

 
ingemar@linux: ~ $ cd

ingemar@linux: ~ $ vi .bashrc

alias sql='sqlplus "/ as sysdba"'
alias sqlplus='rlwrap sqlplus'
alias rman='rlwrap rman'
alias dgmgrl='rlwrap dgmgrl'

alias boston='. ~/.boston'
alias chicago='. ~/.chicago'
alias emrep='. ~/.emrep'

alias test10g='. ~/.test10g'
alias test11g='. ~/.test11g'

alias ll='ls -ltr'

Da er det bare å teste hvordan dine program fungerer.

Lykke til!

]]> http://www.oraklet.no/2009/02/rlwrap/feed/ 0 Flash recovery area og ORA-19809 http://www.oraklet.no/2008/10/flash-recovery-area-og-ora-19809/ http://www.oraklet.no/2008/10/flash-recovery-area-og-ora-19809/#comments Thu, 23 Oct 2008 19:17:33 +0000 ingemar http://www.oraklet.no/?p=56 Har du støtt på Oracle feilmeldingen ORA-19804, ORA-19809 eller ORA-19815 mange ganger?

Dette skyldes at du har nådd den logiske grensen på “flash_recovery_area” i Oracle-terminologien. Jeg mener dette er en feil i rutinen til programmet som oppretter databasen – database konfigurasjons assistenten dbca og skyldes som regel at du har beholdt standard oppsettet på DB_RECOVERY_FILE_DEST_SIZE som er 2 GB.

Hva er riktig størrelse?

Som regel benytter man et stort område til å lagre arkivfiler og sikkerhetskopi av databasene. Og derfor burde database konfigurasjons assistenten vært mer nøyaktig om hvilke konsekvenser denne feilen får. Konsekvensen er at databasen stopper helt til du enten rydder plass eller endrer størrelsen til noe mer realistisk, for eksempel 90% av den plass du har avsatt for arkivering og sikkerhetskopier av databasen. Har du flere databaser på samme server konkurrerer de muligens også om den samme plassen.

Begynn med å sjekke alert-loggen

Alert loggen er et bra sted å søke i når denne logiske grense er nådd. Det kan da se slik ut:


ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
Creating archive destination file : /oradata/flash_recovery_area/PROD/archivelog/2008_09_26/o1_mf_1_10164_0_.arc (189364 blocks)
Fri Sep 26 18:06:36 2008
Errors in file /oracle/admin/PROD/udump/prod_rfs_17303.trc:
ORA-00270: error creating archive log /oradata/flash_recovery_area/PROD/archivelog/2008_09_26/o1_mf_1_10164_%u_.arc
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 96954368 bytes disk space from 53687091200 limit

Du kan også bruke Oracle-kommandoen oerr for å få en forklaring til disse ORA- feilmeldingene. Denne kommandoen finnes kun på Linux og Unix plattformen.


oracle@xps:~$ oerr ora 19809
19809, 00000, "limit exceeded for recovery files"
//*Cause: The limit for recovery files specified by the
//        DB_RECOVERY_FILE_DEST_SIZE was exceeded.
//*Action:The error is accompanied by 19804. See message 19804 for further
//        details.

oracle@xps:~$ oerr ora 19804
19804, 00000, "cannot reclaim %s bytes disk space from %s limit"
// *Cause: Oracle cannot reclaim disk space of specified bytes from the
//         DB_RECOVERY_FILE_DEST_SIZE limit.
// *Action: There are five possible solutions:
//          1) Take frequent backup of recovery area using RMAN.
//          2) Consider changing RMAN retention policy.
//          3) Consider changing RMAN archivelog deletion policy.
//          4) Add disk space and increase DB_RECOVERY_FILE_DEST_SIZE.
//          5) Delete files from recovery area using RMAN.

Hvor mye ledig plass gjenstår?

Ønsker du å sjekke hvor mye plass som er benyttet kan følgende SQL brukes:


SYS@PROD SQL> SELECT (100 - sum(percent_space_used))
                              + sum(percent_space_reclaimable)
                              "Prosent ledig plass"
                              FROM v$flash_recovery_area_usage;

Prosent ledig plass
-------------------
	      84,09

Løsningen på problemet er indikert i såvel alert loggen som ORA-teksten og en enkel variant er å endre parameteren DB_RECOVERY_FILE_DEST_SIZE til å bedre indikere hvor stor plass som er avsatt til dette området. SQL-en ser da slik ut:


SYS@PROD SQL> ALTER SYSTEM SET
                              db_recovery_file_dest_size = 100G;

Hvis du ønsker en tilbakemelding neste gang området er på vei å fylles opp kan du enten benytte deg av Oracle Enterprise Manager eller overvåkingsprogrammet dbWatch. dbWatch har etterhvert fått stor anerkjennelse og fikk en 5-stjerners vurdering i juli.

]]> http://www.oraklet.no/2008/10/flash-recovery-area-og-ora-19809/feed/ 0 Bør du oppgradere Oracle, eller vente? http://www.oraklet.no/2008/10/b%c3%b8r-du-oppgradere-oracle-eller-vente/ http://www.oraklet.no/2008/10/b%c3%b8r-du-oppgradere-oracle-eller-vente/#comments Mon, 20 Oct 2008 20:50:28 +0000 ingemar http://www.oraklet.no/?p=13 Ofte får jeg spørsmålet av mine kunder om de trenger å oppgradere Oracle databasene sine til den siste versjonen. Det man må vurdere er om det er lurt å vente med oppgraderingene for å ta et kjerring tak eller om det lureste er å oppgradere jevnt og trutt.

Kunden sier ofte at alt fungerer og at de er fornøyde med tingenes tilstand. Jeg begynner da med å stille noen kontrollspørsmål som for eksempel hvilken versjon av Oracle de benytter, hvor mange forskjellige versjoner de har og kanskje jeg også spør litt om bedriftens sikkerhets policy. Svaret kan da bli at de har Oracle8i, Oracle9i og muligens også noen Oracle10g databaser. Litt forskjellige versjoner som oftest. Hører jeg at de bruker Oracle8i eller Oracle9i spør jeg litt forsiktig om de vet hvilke versjoner som er supportert av Oracle. Om sikkerheten får jeg høre at den er høy fordi de har investert i en brannmur og da er det ikke noe problem.

Litt moro er det også å se litt forsiktig i hyllene til kundene. Ser jeg at de samler på dokumentasjon fra Oracle7 eller Oracle8i skjønner jeg at tiden har stått stille lenge (men det kan jeg ikke si).

Mulighetene venter på deg

Nå kunne jeg ha hevdet at du bør oppgradere fordi da får du adgang til alle de nye, deilige funksjonene som ligger der og venter på deg, men sannheten er at de fleste kundene nesten ikke bruker noe av dette. Mange av databasene bruker så få muligheter at de fint kunne kjørt på Oracle7 (det er derfor de har beholdt dokumentasjonen…), men jeg har flere begrunnelser for hvorfor du bør oppgradere.

Support

For det første kan du regne med bedre oppfølgning fra Oracle support hvis du en dag trenger hjelp. Det er et ufravikelig faktum at de kundene som benytter de siste versjonene av Oracle stiller i en særklasse her. Men når det er sagt er Oracle support blitt flinkere til å bistå også når du trenger assistanse vedrørende en noe eldre versjon av databasen.

Oracle8i, Oracle9i, Oracle10g og nå Oracle11g

For øyeblikket finnes det to versjoner det er aktuelt å oppgradere til: Oracle10g R2 versjon 10.2.0.4 og Oracle11g R1 versjon 11.1.0.7. Det vil si versjon 2 av Oracle10g og versjon 1 av Oracle11g. Som en liten parentes kan vi se et øyeblikk tilbake til tidligere versjoner av Oracle. Oracle8 versjon 0 (8.0.6) var det ikke mange som benyttet, de ventet til versjon 1 som fikk navnet Oracle8i kom, i’en markerte at det vare en database for Internet. Det samme gjaldt Oracle9i versjon 0 (9.0.1), de fleste ventet til Oracle9i versjon 2 kom. Nå gjentar seg det med Oracle10g hvor det er få kunder som har installert versjon 1. Nå når Oracle10g versjon 2 har vært ute en tid kan vi forvente oss at kunder begynner å tenke på å oppgradere.

Kjente feil

Sjekker vi hvor mange kjente feil som finnes i de forskjellige versjonene av Oracle10g R2 kan følgende figur gi en oversikt:

Oracle10g Server 10.2.0.1 10.2.0.2 10.2.0.3 10.2.0.4
Totalt dokumenterte feil 346 793 1974
Ikke dokumenterte feil i Oracle Server 420 387 664
Ikke dokumenterte feil i Oracle OLAP 100 92 1

Tabellen skal leses slik at om du oppdaterer fra versjon 10.2.0.3 til 10.2.0.4, er 1974 dokumenterte feil rettet i Oracle server-koden. Oppgraderer du fra versjon 10.2.0.1 til 10.2.0.4 er 3113 dokumenterte feil blitt rettet. Du ser også at antallet rettede feil er mye høyere i 10.2.0.4 i forhold til tidligere versjoner. Dette skyldes at fler kunder har tatt i bruk produktet og dermed blir flere feil oppdaget og rettet.

Hvis vi ser på antallet ikke dokumenterte feil som er blitt rettet er tendensen også at det er blitt rettet noen fler feil i den siste versjonen av Oracle 10g R2. Ser vi på de andre produktene er det vært å merke seg at antallet ikke dokumenterte feil i OLAP-modulen (online analytisk prosesseringløsning) har gått ned fra 100 til 1! Dette er et produkt som ikke mange kunder har tatt i bruk enda, men det er antageligvis viktig for de kundene som benytter det. Moralen her må være: Ikke bruk OLAP i noen lavere versjon enn 10.2.0.4.

Jeg vil med andre ord anbefale de fleste kundene å oppgradere til Oracle10g versjon 10.2.0.4. Dette leder oss til neste avsnitt: Hvordan?

Hvordan oppgraderer vi?

En mulighet i Oracle10g R2 er å klone installasjonen, dvs. du kopierer den versjonen du har til en ny katalog og oppgraderer derfra. Dermed kan du oppgradere i kontrollerte former, først lytteprosessen i SQL*Net, deretter ASM (om du benytter deg av dette), så kommer den minst viktige databasen eller en test database. Du tar alle databasene i tur og orden med den mest kritiske sist. Denne måten er spesielt gunstig på Windows hvor du ellers må regne med å starte maskinen på nytt for å få begynt oppgraderingen.

Kloningen kan du utføre slik. Her vises eksempel som kan brukes i Unix og Linux. Du erstatter …/10.2.0/db_1 med …/10.2.0.4/db. Min begrunnelse for dette er at db_1 gir ikke noen informasjon, 10.2.0.4 forteller akkurat hva denne katalogen inneholder.

oracle@ferrari:~ $echo $ORACLE_HOME
/oracle/product/10.2.0/db_1
oracle@ferrari:~ mkdir /oracle/product/10.2.0.4/db
oracle@ferrari:~ cp -rp $ORACLE_HOME /oracle/product/10.2.0.4/db
oracle@ferrari:~ cd /oracle/product/10.2.0.4/db/clone/bin
oracle@ferrari:bin perl ./clone.pl ORACLE_HOME='/oracle/product/10.2.0.4/db' ORACLE_HOME_NAME='Oracle_10204'    
...
oracle@ferrari:bin sudo /oracle/product/10.2.0.4/db/root.sh
...


Når du har klonet Oracle til en ny katalog, oppgraderer du denne, ikke den gamle versjonen. Det aller beste er at du kan utføre dette i et test miljø, pakke det sammen, kopiere over til ditt utviklings og produksjonsmiljø, kjøre klone programmet og du er 100% sikker på at alle installasjonene er like. Dette uten å ha startet Oracle Universal Installer - OUI. Nå har du en ny versjon ved siden av den gamle som du kan flytte over passord-fil og parameter- eller serverparameter-fil (spfile) til innen du oppgraderer databasene. Kan det utføres enklere?

Selvfølgelig bør du ha studert relevante README dokumenter. I denne forbindelse anbefales spesielt 10g Upgrade Companion beskrevet i Metalink notat 466181.1. Jeg mener denne håndboken bør være obligatorisk lesning for alle som planlegger en oppgradering.

Noen overraskelser kan du få på veien når du oppgraderer databasen. For eksempel inneholder CONNECT rollen kun CREATE SESSION rettigheten i Oracle10g R2. Dette oppdager du når du tester og endrer i god før produksjonsystemet står for tur, ikke sant!

Som et siste tips hvis du velger å oppgradere til Oracle11g er det en ting du bør huske på, det skilles mellom store og små bokstaver i passord som er opprettet for å øke sikkerheten. Dette er selvfølgelig en fordel men kan gi litt trøbbel i for eksempel database linker hvor det står:

 ...IDENTIFIED BY passord...;

Det burde ha stått:

 ...IDENTIFIED BY 'passord'...;

Dette for å være sikker på at linken fungerer i Oracle11g. Du så forskjellen? Apostrofer rundt passordet.

Oracle10g R2 eller Oracle11g R1

Så er da spørsmålet: skal jeg oppgradere til 10g eller 11g? Svaret er som oftest hva er kritiske faktorer for deg i ditt prosjekt? Trenger du trygghet - velg Oracle10g R2, trenger du noe som kun 11g kan tilby som for eksempel bedre passordhåndtering eller bedre håndtering av partisjoner, vurder Oracle11g R1.

Lykke til med oppgraderingene og husk å dobbelsjekke sikkerhetskopien innen du begynner...

]]> http://www.oraklet.no/2008/10/b%c3%b8r-du-oppgradere-oracle-eller-vente/feed/ 0 SQL-prompt i Oracle http://www.oraklet.no/2006/11/hello-world/ http://www.oraklet.no/2006/11/hello-world/#comments Sun, 26 Nov 2006 13:46:23 +0000 ingemar http://192.168.2.114/?p=1 Bruker du også SQL*Plus når du arbeider i Oracle? Da har jeg et tips til deg.

Det første jeg gjør når jeg arbeider i en ny database er å redigere SQL-prompten. Da vises navnet du har logget inn med og instanse navnet i prompten.

Variabelen sqlprompt defineres enten i filen glogin i katalogen $ORACLE_HOME/sqlplus/admin eller i lokal fil login.sql. Arbeider du fra en klient utføres endringen der.

SQL-prompt i Oracle10g og Oracle11g

 SET sqlprompt “_USER’@'_CONNECT_IDENTIFIER SQL> “

Og resultatet blir:

 SYS@DW SQL> 

Dette kan du lese mere om i Oracle dokumentasjonen, Oracle10g og Oracle11g.

SQL-prompt i Oracle9i

I Oracle9i kan du ikke bruke denne metoden uten må jukse litt. Her ser du en mulig løsning:

-- Definert av Ingemar J. Haverstad
SET TERMOUT OFF

DEFINE gname=idle

COLUMN global_name new_value gname

SELECT LOWER(user) || '@' ||
  SUBSTR(global_name, 1,
                decode(dot, 0, LENGTH(global_name), dot-1)) global_name
  FROM (SELECT global_name, INSTR(global_name, '.') dot
FROM global_name);

SET sqlprompt '&gname SQL> '

SET TERMOUT ON

Denne er litt mer tungvint men kanskje OK allikevel.

SQL-prompt i Data Guard

Dette leder oss til en variant som jeg bruker i Data Guard. Utfordringen her er å vite om man er i primærbasen eller i Data Guard databasen. Følgende knep kan brukes:

 -- Definert av Ingemar J. Haverstad
SET TERMOUT OFF

DEFINE g_name=idle

COLUMN global_name new_value g_name

SELECT '[' || database_role || '] ' ||
  LOWER(user) || '@' ||
  db_unique_name global_name
FROM v$database;

SET sqlprompt '&g_name SQL> '

SET TERMOUT ON

Resultatet blir følgende i primær databasen:

 [PRIMARY] sys@CHICAGO SQL>

Resultatet blir følgende i standby databasen:

 [PHYSICAL STANDBY] sys@BOSTON SQL>

Vakkert, ikke sant!

SQL-prompt i Real Application Cluster

Noe liknende kan også brukes i Real Application Cluster miljøer. Her er det en fordel å angi hvilken av flere instanser du er innlogget på. Dette vises best med et eksempel:

 -- Definert av Ingemar J. Haverstad
SET TERMOUT OFF

DEFINE g_name=idle

COLUMN global_name new_value g_name

SELECT
  LOWER(user) || '@' ||
  instance_name global_name
FROM v$instance;

SET sqlprompt '&g_name SQL> '

SET TERMOUT ON

Resultatet blir følgende når system brukeren er pålogget første instansen:

 system@PROD1 SQL>

Og resultatet blir følgende når system brukeren er pålogget andre instansen:

 system@PROD2 SQL>
]]> http://www.oraklet.no/2006/11/hello-world/feed/ 0