Please enable JavaScript to view this site.

Invantive Estate

Perform the following steps for an installation or an upgrade:

Check if Oracle RDBMS 11.2.0.3 or 12.1.0.2 Standard Edition One, Standard Edition or Enterprise Edition is installed and configured (see next chapter for the steps). The functioning of Invantive Estate with other Oracle RDBMS versions is not guaranteed.

The database character set must be AL32UTF8.

[UNIX/Linux] The NLS_LANG environment variable needs to be set to ‘DUTCH_THE NETHERLANDS.AL32UTF8’ for all users, on the web server and on the database server.

[Windows] The HKLM\Software\Oracle\Key_Ora*\NLS_LANG register variable needs to be set to ‘DUTCH_THE NETHERLANDS.AL32UTF8’ for all users, on the web server and on the database server:

NLS_LANG to be set on Unicode

Depending on the prevailing security policy you might want to turn off the automatic blocking of accounts by several false attempts to log on. It is common that a password is changed and the auto-retry functionality of Invantive Estate makes that an account will be blocked. Log on as ‘sys’ (for example with SQL*Plus) and execute:

alter profile default

limit

failed_login_attempts unlimited

password_life_time unlimited

password_reuse_time unlimited

password_reuse_max unlimited

password_lock_time 1

password_grace_time 30;

Possibly change the global name of the service:

alter database rename global_name to "orcl11r1.NAAMBEDRIJF.nl" scope=spfile; -- 11g R1

alter database rename global_name to "orcl11r2.NAAMBEDRIJF.nl"; -- 11g R2

If necessary, change the name under which the database register with the listener:

alter system set service_names='orcl11r1.NAAMBEDRIJF.nl' scope=spfile;

alter system set db_domain='NAAMBEDRIJF.nl' scope=spfile;

Change the NLS settings of the database server:

alter system set nls_language='DUTCH' scope=spfile;

alter system set nls_territory='THE NETHERLANDS' scope=spfile;

Change the parameter memory_target in at least 40 MB times the number of simultaneous users with a minimum of 768 MB, for example, with:

 

alter system set memory_target=512m scope=spfile;

 

Put memory_max_target at at least the same value as memory_target and possibly higher.

Remember to put sga_target and pga_aggregate_target to 0, for example, with:

 

alter system set sga_target=0 scope=spfile;

alter system set pga_aggregate_target=0 scope=spfile;

alter system set shared_pool_reserved_size=0 scope=spfile;

Make sure that dumps do not take up the entire server:
 

alter system set max_dump_file_size="8M";

Check that automatic memory management is used optimally:

 

select name

, value

from   v$parameter

where  1=1

and    name like '%size'

and    value <> '0'

and    name not like 'sga%'

and    name not like 'db_block%'

and    name not like 'max_dump%'

and    name not like '%percent%'

and    name not like '%message%'

and    name not like 'object_cache%'

and    name not like 'db_recovery_file_dest_size%'

To prevent the flooding of the disks in the case of malfunctions you might want to ease the automatic registration of incidents.

$ adrci
#
# Reduce minimum duration for trace files to 2 hours.
# And 8 hours for incidents.
#

set control (shortp_policy = 2)

set control (longp_policy = 8)

#

# Or regularly execute:

#

set base /opt/prd/oracle

show homes

 

set homepath diag/rdbms/prd11r2/prd11r2

show incident

purge -age 1440

set control (shortp_policy = 2)

set control (longp_policy = 8)

 

set homepath diag/tnslsnr/ws86/listener

show incident

purge -age 1440

You should change the settings for the database optimizer if the web frontend does not respond fast for example in the processes screen and in case you make use of the <OMGEVING>_web schedule for the web frontend:

 

alter system set "_optimizer_cost_based_transformation" = off scope=both

You can check if the data ends up in the right place in a production environment by changing the log file several times using the underlying statement. If necessary, change the log_archive_dest_1 parameter.

 

alter system switch logfile

Within demo installations you can avoid the possibly massive startup of database jobs and the corresponding inertia by turning them off:

 

begin

 for r_job

 in

 ( select sjb.owner

   ,      sjb.job_name

   ,      sjb.enabled

   from   dba_scheduler_jobs sjb

   where  sjb.enabled = 'TRUE'

   order

   by     sjb.owner

   ,      sjb.job_name

 )

 loop

   begin

     dbms_scheduler.stop_job(r_job.owner || '.' || r_job.job_name, true);

   exception

     when others

     then

       null;

   end;

   dbms_scheduler.disable(r_job.owner || '.' || r_job.job_name);

 end loop;

end;