Å 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 fra /u04 til /u05.

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 '/u05/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=/u05/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%';

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: /u05/oradata/DR1R/DR1R_users_01.dbf

        Tag: TAG20100316T075530

RMAN> SWITCH DATAFILE 8 TO COPY;

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

RMAN> LIST COPY LIKE '%users%';

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 /u05/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

You as a customer may be happy with the way the database is working today – If it works, don’t touch, it is a saying out there. I usually start with asking which version of Oracle they do have, and how many different versions they have altogether. I may as well ask what their security policies are and if they care for getting appropriate support. The answer is often that they have a mixture of Oracle9i, Oracle10g R1 and perhaps also some Oracle10g R2 databases. Oracle9i hasn’t been supported by Oracle for a while and Oracle10g will soon loose its ordinary support status. Security is as always very good because they have invested in a firewall and DMZ and all that stuff, I’m told.

It is always interesting to see what literature they have in their book shelves. Sometimes I find Good Old Oracle7 or Oracle8i manuals. By the way, may favourite URL for Oracle documentation is http://tahiti.oracle.com. It has almost everything I’m looking for.

Now is the right time!

I could of course told you that you should upgrade because you will get access to all these nice and cute little features waiting for you, but the truth is that most customers doesn’t care!
Most applications are only using a few of the possibilities available in newer releases, that’s why they kept the old documentation. However, I have plenty of reasons why you should upgrade.

Support

First of all, you get much better support when you are on track with the releases. You are the King!

Oracle9i, Oracle10g R1, Oracle10g R2 and now Oracle11g R1 and R2

There are, for the moment two releases you should consider upgrading to: Oracle11g R1 version 10.1.0.7 or Oracle11g R2 version 11.2.0.1. That is, version 1 or 2 of Oracle11g. Looking back in time at the earlier releases of Oracle. Oracle8 version 0 (8.0.6) was only used by a handful customers in Norway, they waited until version 1 came along, named Oracle8i, The i indicated that it was a database for the Internet. Same story with Oracle9i version 0 (9.0.1), most customers waited for Oracle9i version 2. Exactly the same happened with Oracle10g where only a few customers went production with version 1 (version naming started with 1 not 0, for a change). g in the name, was that for Grid or GB! Now most customers are at Oracle10g version 2 as it has been out there for some time. Not many customers are running Oracle11g R1, they are instead going for R2.

Known errors

It could be of interest to see how many documented errors there is in a release. Let’s take a look at Oracle10g R2:

The table should be read like this: if you upgrade from version 10.2.0.3 to 10.2.0.4, there are 1974 documented errors which has been corrected in the Oracle server-code. Upgrading from version 10.2.0.1 to 10.2.0.4 shows that 3113 documented errors has been corrected. You will also notice that the rate which the errors has been corrected is accelerating in 10.2.0.4 compared to earlier releases. The reason for that is that the more customers using the product, the more errors get corrected.

Looking at the numbers for undocumented errors shows the same trend, highest number for the last version of Oracle 10g R2. It is also interesting to observe that the number of undocumented errors in the OLAP-module (Online Analytical Processing) went down from 100 to 1! This means that if you are using OLAP, go for 10.2.0.4 or higher.

So, if you haven’t upgraded to Oracle11g yet, now is the time.

How to upgrade?

Ii is possible in Oracle10g R2 and above to clone the Oracle software. That is, you can copy your software from one directory to another. That means that you can keep the old version and upgrade a copy of it. You can upgrade parts of your installation. Start with the listener process in SQL*Net, continue with ASM (if you are using ASM), upgrade a test database, then the least important production database. Each database one by one. This method is even more useful on Windows where you may have to reboot the system if upgrading the original software.

Cloning of the Oracle software is described here. This example is for Linux and Unix. Substitute …/10.2.0/db_1 with …/10.2.0.4/db. I prefer db instead of db_1 as it doesn’t really tell what the 1 is for, 10.2.0.4 indicates which minor release is in use also.

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
...

When you have cloned Oracle to a new directory, upgrade that one, not the original one. Start with a test or reference environment, zip it or create a tar-file, copy it over to your development and finally to your production environment.
This way, you 100% sure all environments are the same, and you save time. All these, without having started the Oracle Universal Installer – OUI, more than once. Move password file and server parameter file (spfile) to your newly created ORACLE_HOME before you upgrade the database. Isn’t it easy?

But, before you start, make sure you have read all relevant README documents, of course. I would highly recommend 11g Upgrade Companion in Metalink note 466181.1. This is mandatory reading planning to upgrade an Oracle database.

Anyway, a few surprises on your way may happen while upgrading. For instance, the CONNECT role has only CREATE SESSION privilege in Oracle10g R2. But that’s taken care of while testing.

Please do note that there is at least one important thing in Oracle11g. You have the option of separating lower case from upper case in passwords. This is a good feature but may be overlooked in different places such as database links. Suppose you write the SQL like this:

 ...IDENTIFIED BY password...;

Should have been:

 ...IDENTIFIED BY 'password'...;

That way, the link will still work in Oracle11g. You noticed the difference? Single quote around the password.

Oracle11g R1 or Oracle11g R2

The question is: should I upgrade to R1 og R2? Well, for Windows, you still have to wait for R2. Unix and Linux shops can choose and decide what is most appropriate for them.

Good luck with the upgrade and remember to double check your backup before you start…

The reason for this message is that your database have reached the logical, or in worst case physical limit of «flash_recovery_area» in the Oracle-lingo. This is a side effect from the configuration assistant creating the database dbca, this is because you may have followed the instructions for a DEFAULT installation, which sets the database parameter DB_RECOVERY_FILE_DEST_SIZE to 2 GB.

What is the correct size for the Flash Recovery Area?

Most database administrators allocate a huge area for archive files and backup of the database. The configuration assistant should indicate the consequences having a too small Flash Recovery Area. You may end up with a hanging database, hanging until you either clean up some disk space or change this parameter to something more realistic. For instance, 90% of the space you have set aside for backup.
Things get more complicated if you have more databases using the same Flash Recovery Area, because they will compete for the same space…

First of all, check the alert-log.

The Alert log is usually a good starting point while in trouble. The message you should look for is easy to recognize:

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

You may also use a Oracle command oerr to check out what the error is all about. oerr is only available on the Linux and Unix platforms.

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.

SYS@PROD SQL> SELECT (100 - sum(percent_space_used))
                              + sum(percent_space_reclaimable)
                              "Percent free space"
                              FROM v$flash_recovery_area_usage;

Percent free space
------------------------------
    	             84,09

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

The program has already been compiled if working with Ubuntu Linux, all you need is to download the program from the net:

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

Some other Linux or Unix dialects do have a similar approach. However, you may have to compile the program yourself.
Use your favourite search engine to locate an appropriate site where you can download the source code for rlwrap. Go ahead and compile the code:

 
[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

You may have to download a few more libraries if that is not done already for your system in order to get rlwrap to compile.

 
[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

Having compiled and installed rlwrap leads us to the next step. Add some aliases to for instance .bashrc is handy. Use rlwrap in all programs where it is relevant. Here are a few examples:

 
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'

Finally, test the aliases and see how it works.
Good Luck!

The first thing I change when working in a new database environment is, of course, the SQL-prompt. The prompt could for instance show you which user you are logged in as and which instance in the prompt itself.

The variable sqlprompt could be defined either in the file glogin in the directory $ORACLE_HOME/sqlplus/admin or in local file login.sql. You could also change the same files on the client you are working from.

SQL-prompt in Oracle10g and Oracle11g

 SET sqlprompt “_USER’@'_CONNECT_IDENTIFIER SQL> “

And the result is:

 SYS@DW SQL> 

You may read more about this in the Oracle documentation, Oracle10g and Oracle11g.

SQL-prompt in Oracle9i

This method is not working for Oracle9i, it is a bit more complicated. One solution may look like this:

-- Defined by 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

SQL-prompt in Data Guard

This leads us to a variation I’m often using with Data Guard. The challenge in this case is to know if you are working in the primary or standby database. Following lines makes it easier:

 -- Defined by 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

The result will look like this while connected to the primary database:

 [PRIMARY] sys@CHICAGO SQL>

And, in the standby database:

 [PHYSICAL STANDBY] sys@BOSTON SQL>

Nice, isn’t it!

SQL-prompt in a Real Application Cluster (RAC)

Something similar could also be used in Real Application Cluster environments. It is obviously good to know which instance you are logged on to, at least as a database administrator. I will show this with an example:

 -- Defined by 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

The result should look like this when the system user is logged on to the first instance in the cluster:

 system@PROD1 SQL>

And, of course, like this on the second instance:

 system@PROD2 SQL>

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!

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.

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

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

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:

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…

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>