Eerste indruk Oracle Enterprise Manager Grid Control 11G

Bij de eerste installatie stappen rijzen er gelijk een aantal vragen.

  • Vreemd dat er in de te downloaden installatie set geen middleware en database wordt meegeleverd, terwijl de installatie set weer gegroeid is ten opzichte van 10.2.0.5.0, die 10.2.0.3.0 minstens als basis nog had.
  • Nu is de applicatie Enterprise Manager Grid Control vrij te gebruiken, als je de management packs maar niet inschakeld, maar hoe zit dit dan met de weblogic server en de enterprise database die je nodig hebt.

Hieronder staan wat screenshots van de installatie procedure van EM 11g. Voordat je dit kan uit voeren heb je een Weblogic Server nodig, dit kan een kale installatie zijn zonder domein en je hebt een database nodig met partitioning. In mijn geval heb ik de database en de weblogic server op dezelfde machine geïnstalleerd op 64 bits Oracle Enterprise Linux 5.5. Deze machine heeft in totaal 4 GB geheugen waarvan er 512 MB is toegekend aan de database.

Nadat de database gecreëerd is moet je er nog even voor zorgen dat het aantal ‘processes’, ‘session_cached_cursors’ en ‘log_buffers’ goed staan. Verder moet er minimaal 200 MB aan undotablespace beschikbaar zijn.

SQL> alter system set processes=500 scope=spfile;

System altered.

SQL> alter system set session_cached_cursors=200 scope=spfile;

System altered.

SQL> alter system set log_buffer=10485760 scope=spfile;

System altered.

SQL> alter database datafile 'UNDO_DATAFILE' resize 200M;

Database altered

SQL> shutdown immediate
SQL> startup

Installatie:

Eerste indruk:

Op het eerste gezicht lijkt er niet veel aangepast, anders dan dat er onder de motorkap veel gewijzigd is. De applicatie reageert snel, verder zijn er wel wat iconen anders opgemaakt, maar alle functies zijn nog terug te vinden onder de wel bekende locaties.

Waar je vooral ziet dat dit de nieuwe Enterprise manager is, is in de management console voor de Weblogic applicatie server. De interface zoals je die gewend bent in de Admin Server van Weblogic is in EM overgenomen. Dit werkt zeer prettig.

Error during yum update

When running yum update to bring Oracle Enterprise Linux 5.4 to version 5.5 I got the following error:

Transaction Check Error:
file /usr/share/locale/hu/LC_MESSAGES/firstboot.mo from install of firstboot-1.4.27.8-1.0.2.el5.i386 conflicts with file from package firstboot-tui-1.4.27.7-1.0.1.el5.i386
file /usr/share/locale/nb/LC_MESSAGES/firstboot.mo from install of firstboot-1.4.27.8-1.0.2.el5.i386 conflicts with file from package firstboot-tui-1.4.27.7-1.0.1.el5.i386
file /usr/share/locale/no/LC_MESSAGES/firstboot.mo from install of firstboot-1.4.27.8-1.0.2.el5.i386 conflicts with file from package firstboot-tui-1.4.27.7-1.0.1.el5.i386
Error Summary

To solve it I remove the conflicting package

yum erase  firstboot-tui-1.4.27.7-1.0.1.el5.i386
yum install firstboot.i386
yum update -y

Checkpoint not complete

Today I had a weird issue on a 10G database. The database was not doing very much and although the redo log files where not full, the database performed a log switch every 10 minutes. And I kept seeing “Checkpoint not complete” in the alertlog. When I looked in the database I noticed that 2 out of 3 log groups where active and 1 current. So I was searching what made the database switch the logfile, although it was not full yet. After a while I found that the parameter archive_lag_target was set to 600 seconds, what explained the log switch every 10 minutes. And since the default value of log_checkpoint_timeout is 1800 seconds explained why the checkpoint not complete messages kept appearing. Solution to this issue in my case, add an extra log group, or even better yet set the log_checkpoint_timeout to the same value as archive_lag_target.

In my case it was not an option to disable the archive_lag_target, since this is an parameter that has been set from a business point of view. No more then 10 minutes loss of data in case op a failure.

Sample of the logfile:

<em>Wed Feb 17 18:31:43 2010
Thread 1 cannot allocate new log, sequence 66738
Checkpoint not complete
Current log# 1 seq# 66737 mem# 0: <ORADATA>ONLINELOGO1_MF_1_43F0DRVC_.LOG
Current log# 1 seq# 66737 mem# 1: <ORADATA>ONLINELOGO1_MF_1_43F0DSX9_.LOG
Thread 1 cannot allocate new log, sequence 66738
Private strand flush not complete
Current log# 1 seq# 66737 mem# 0: <ORADATA>ONLINELOGO1_MF_1_43F0DRVC_.LOG
Current log# 1 seq# 66737 mem# 1: <ORADATA>ONLINELOGO1_MF_1_43F0DSX9_.LOG
Wed Feb 17 18:31:49 2010
Thread 1 advanced to log sequence 66738 (LGWR switch)
Current log# 3 seq# 66738 mem# 0: <ORADATA>ONLINELOGO1_MF_3_43F0F1RW_.LOG
Current log# 3 seq# 66738 mem# 1: <ORADATA>ONLINELOGO1_MF_3_43F0F4HN_.LOG
Wed Feb 17 18:41:49 2010
Thread 1 cannot allocate new log, sequence 66739
Checkpoint not complete
Current log# 3 seq# 66738 mem# 0: <ORADATA>ONLINELOGO1_MF_3_43F0F1RW_.LOG
Current log# 3 seq# 66738 mem# 1: <ORADATA>ONLINELOGO1_MF_3_43F0F4HN_.LOG
Thread 1 cannot allocate new log, sequence 66739
Private strand flush not complete
Current log# 3 seq# 66738 mem# 0: <ORADATA>ONLINELOGO1_MF_3_43F0F1RW_.LOG
Current log# 3 seq# 66738 mem# 1: <ORADATA>ONLINELOGO1_MF_3_43F0F4HN_.LOG
Wed Feb 17 18:41:55 2010
Thread 1 advanced to log sequence 66739 (LGWR switch)
Current log# 2 seq# 66739 mem# 0: <ORADATA>ONLINELOGO1_MF_2_43F0DWF5_.LOG
Current log# 2 seq# 66739 mem# 1: <ORADATA>ONLINELOGO1_MF_2_43F0DZ1G_.LOG
Wed Feb 17 18:51:53 2010
Thread 1 cannot allocate new log, sequence 66740
Checkpoint not complete
Current log# 2 seq# 66739 mem# 0: <ORADATA>ONLINELOGO1_MF_2_43F0DWF5_.LOG
Current log# 2 seq# 66739 mem# 1: <ORADATA>ONLINELOGO1_MF_2_43F0DZ1G_.LOG
Thread 1 cannot allocate new log, sequence 66740
Private strand flush not complete
Current log# 2 seq# 66739 mem# 0: <ORADATA>ONLINELOGO1_MF_2_43F0DWF5_.LOG
Current log# 2 seq# 66739 mem# 1: <ORADATA>ONLINELOGO1_MF_2_43F0DZ1G_.LOG
Wed Feb 17 18:51:59 2010
Thread 1 advanced to log sequence 66740 (LGWR switch)
Current log# 1 seq# 66740 mem# 0: <ORADATA>ONLINELOGO1_MF_1_43F0DRVC_.LOG
Current log# 1 seq# 66740 mem# 1: <ORADATA>ONLINELOGO1_MF_1_43F0DSX9_.LOG