From:                                         Pascal FAURE <pfaure@db1.fr>

Sent:                                           samedi 13 octobre 2012 16:42

To:                                               dba@client3.com;manager@client3.com

Cc:                                              developpeur@client3.com;utilisateur@client3.com

Subject:                                     RE: Performances VBank/Oracle

 

Bonjour,

 

La réorganisation est terminée.

les accès aux deux tables les plus volumineuses (SAFLIN et SAPRAG) seront donc plus rapides.

J’ai aussi modifié la destination des archives log de SRF (G  -> I ) pour éviter les blocages des semaines précédentes.
Je me connecterai Lundi matin de bonne heure pour être  plus réactif en cas de nouveau problème.

 

Cordialement,

 

Pascal FAURE
Consultant Oracle 

Tél : 06 07 60 08 96


Description: Description: Description: cid:910CBE1D-DDA4-4962-B24C-8D5D2884BB9E

Tél : 08 20 22 00 80

Fax  04 76 63 35 37 
www.db1.fr

 

 

 

From: Pascal FAURE [mailto:pfaure@db1.fr]
Sent: vendredi 12 octobre 2012 15:38
To: dba@client3.com;manager@client3.com
Cc:  developpeur@client3.com;utilisateur@client3.com
Subject: RE: Performances VBank/Oracle

 

Bonjour,

 

J’ai programmé la réorganisation des tables SAFLIN et SAPRAG pour 18H00 ce soir, je surveillerai ce job ce soir et demain s’il le faut, de manière à ce qu’il n’y ait pas de problèmes Lundi matin. Ce type de réorganisation n’impose pas l’arrêt des applications mais peut ralentir les traitements et bloquer un moment des mises à jours sur ces 2 tables , il est donc plus prudent de la lancer en dehors des heures de pointe.

 

BEGIN

sys.dbms_scheduler.create_job(

job_name => '"SYSTEM"."REORG_SRF"',

job_type => 'PLSQL_BLOCK',

job_action => 'begin

alter table VBANK.SAFLIN enable row movement;

alter table VBANK.SAFLIN shrink space;

alter table VBANK.SAFLIN disable row movement;

alter table VBANK.SAPRAG enable row movement;

alter table VBANK.SAPRAG shrink space;

alter table VBANK.SAPRAG disable row movement;

alter index VBANK.SAFLIN1 shrink space;

alter index VBANK.SAPRAG3 shrink space;

alter index VBANK.SALPAG1 shrink space;

end;',

start_date => sysdate+2.5/24,

job_class => '"DEFAULT_JOB_CLASS"',

auto_drop => FALSE,

enabled => TRUE);

END;

 

 

Cordialement,

 

Pascal FAURE
Consultant Oracle 

Tél : 06 07 60 08 96


Description: Description: Description: Description: Description: cid:910CBE1D-DDA4-4962-B24C-8D5D2884BB9E

Tél : 08 20 22 00 80

Fax  04 76 63 35 37 
www.db1.fr

 

 

 

From: Pascal FAURE [mailto:pfaure@db1.fr]
Sent: mercredi 10 octobre 2012 16:35
To: dba@client3.com;manager@client3.com
Cc: developpeur@client3.com;utilisateur@client3.com
Subject: RE: Performances VBank/Oracle

 

Bonjour,

 

J’ai analysé l’instance SRF sur la journée de Lundi 8 octobre, je ne vois pas de problèmes de performance classique SQL , mais un blocage sur les archive logs qui est arrivé plusieurs fois , le 4 octobre et le 8 octobre et le 10 octobre le 2eme a persisté pendant plusieurs jours jusqu’au 10 octobre, date à  laquelle l’instance a été arrêté :

 

ARCH: FAL archive failed. Archiver continuing

Thu Oct 04 21:10:58 2012

Errors in file c:\oracle\product\10.2.0\admin\srf3\bdump\srf3_arc2_7204.trc:

ORA-19504: échec de création du fichier "G:\ARC\SRF\ARC35664_0763761581.001"

ORA-27044: impossible d'écrire le bloc d'en-tête du fichier

OSD-04008: échec de Writefile() ; écriture impossible dans le fichier

O/S-Error: (OS 112) Espace insuffisant sur le disque.

 

Mon Oct 08 15:14:58 2012

ARCH: Archival stopped, error occurred. Will continue retrying

Mon Oct 08 15:14:58 2012

Errors in file c:\oracle\product\10.2.0\admin\srf3\bdump\srf3_arc0_7196.trc:

ORA-16038: le journal 3 séquence 35977 ne peut pas être archivé

ORA-19504: échec de création du fichier ""

ORA-00312: journal en ligne 3 thread 1 : 'H:\SRF\BTSP\REDO03.LOG'

 

Ce n’est pas étonnant car cette base a des pics de mise à jour que l’on peut observer dans le tableau ci-dessous , 9 Go de modification le 4 octobre et 2,6 Go le 8 octobre, 0.1 Go les autres jours

 

YY   MON DAY Tot_Day    H00    H04    H08    H12    H16    H20

---- --- --- ------- ------ ------ ------ ------ ------ ------

2012 09  26      1.3     .0     .0     .0     .7     .5     .1

2012 09  27       .1     .0     .0     .0     .0     .0     .1

2012 09  28       .1     .0     .0     .0     .0     .0     .1

2012 09  29       .1     .0     .0     .0     .0     .0     .1

2012 09  30       .1     .0     .0     .0     .0     .0     .1

2012 10  01       .3     .0     .0     .0     .2     .0     .1

2012 10  02      3.5     .0     .0     .0    3.0     .4     .1

2012 10  03       .6     .0     .0     .0     .5     .0     .1

2012 10  04      9.4     .0     .0    1.1     .0    5.5    2.7

2012 10  05      5.7     .5     .0    1.7    2.9     .5     .1

2012 10  06       .1     .0     .0     .0     .0     .0     .0

2012 10  07       .1     .1     .0     .0     .0     .0     .0

2012 10  08      2.6     .1     .0     .3    1.4     .7     .1

2012 10  09       .2     .0     .0     .0     .0     .0     .1

2012 10  10       .1     .0     .0     .0     .0     .0     .0

 

 

Ci-dessous les ordres insert et update qui étaient consommateur le 4 octobre de 15H00 à 21H00 quand il y a eu cette sur-activité et ce  blocage des archive logs :

 

Description: Description: cid:image003.png@01CDA88E.FF492AE0

2jr0rhybkmrrd

insert into SAPRAG values (:b1, :b2, :b3, :b4, :b5, :b6, :b7, :b8, :b9, :b10, :b11, :b12, :b13, :b14, :b15, :b16, :b17, :b18, :b19, :b20, :b21)

 

9k7rc5h661vkp

update SAFLIN set "SOCIET"=:b1, "ARRETE"=:b2, "SESSION"=:b3, "IDFLUX"=:b4, "MONNAIE"=:b5, "CPTEGENE"=:b6, "CPTEAUXI"=:b7, "NUMORD"=:b8, "TIERCNTP"=:b9, "TIERSJ"=:b10, "CODPROD"=:b11, "CODTITRE"=:b12, "REFERENC"=:b13, "EXPDUREE"=:b14, "DATEDEB"=:b15, "DATEFIN"=:b16, "DATEECHE"=:b17, "UNITDURE"=:b18, "DUREINIT"=:b19, "DURERES"=:b20, "SENS"=:b21, "MONTANT"=:b22, "CACTINTB"=:b23, "DRESINTB"=:b24, "VMTTINTB"=:b25, "INDPREAG"=:b26, "RAPPRO"=:b27, "ATTR1"=:b28, "ATTR2"=:b29, "ATTR3"=:b30, "ATTR4"=:b31, "ATTR5"=:b32, "ATTR6"=:b33, "ATTR7"=:b34, "ATTR8"=:b35, "ATTR9"=:b36, "ATTR10"=:b37, "ATTR11"=:b38, "ATTR12"=:b39, "ATTR13"=:b40, "ATTR14"=:b41, "ATTR15"=:b42, "ATTR16"=:b43, "ATTR17"=:b44, "ATTR18"=:b45, "ATTR19"=:b46, "ATTR20"=:b47, "ATTR21"=:b48, "ATTR22"=:b49, "ATTR23"=:b50, "ATTR24"=:b51, "ATTR25"=:b52, "ATTR26"=:b53, "ATTR27"=:b54, "ATTR28"=:b55, "ATTR29"=:b56, "ATTR30"=:b57, "ATTR31"=:b58, "ATTR32"=:b59, "ATTR33"=:b60, "ATTR34"=:b61, "ATTR35"=:b62, "ATTR36"=:b63, "ATTR37"=:b64, "ATTR38"=:b65, "ATTR39"=:b66, "ATTR40"=:b67, "ATTR41"=:b68, "ATTR42"=:b69, "ATTR43"=:b70, "ATTR44"=:b71, "ATTR45"=:b72, "ATTR46"=:b73, "ATTR47"=:b74, "ATTR48"=:b75, "ATTR49"=:b76, "ATTR50"=:b77, "DURPFIT"=:b78, "DATSCONT"=:b79, "DATRCONT"=:b80, "NOMBRE"=:b81, "CPTEREF"=:b82, "VAL050"=:b83, "ARRESESS"=:b84, "VAL255"=:b85, "REFGARAN"=:b86, "DURRESTR"=:b87, "DATEREVI"=:b88, "DURREVI"=:b89 where rowid = :x 

 

27jqrkgqt5fw3

insert into SAPRTP values (:b1, :b2, :b3, :b4, :b5, :b6, :b7, :b8, :b9, :b10, :b11, :b12, :b13, :b14, :b15, :b16, :b17, :b18, :b19, :b20, :b21, :b22, :b23, :b24, :b25, :b26, :b27, :b28, :b29, :b30, :b31, :b32, :b33, :b34, :b35, :b36, :b37, :b38, :b39, :b40, :b41, :b42, :b43, :b44, :b45, :b46, :b47, :b48, :b49, :b50, :b51, :b52, :b53, :b54, :b55)

 

Il s’agit donc des tables SAPRAG , SAFLIN , SAPRTP , il se trouve que c’est les tables les plus volumineuses en nombre de lignes et en espace 

 

select owner,table_name,num_rows from (select * from dba_tables where num_rows is not null order by num_rows desc) where rownum<50;

OWNER      TABLE_NAME                       NUM_ROWS

---------- ------------------------------ ----------

VBANK      SAFLIN                           41850823

VBANK      SAPRAG                           38801019

VBANK      SALPAG                           34601013

VBANK      CRHEND                            4776310

VBANK      SRTABM                            3754703

VBANK      SAPRTP                            2480507

VBANK      SRCEVE                            2005627

VBANK      SRCIDR                            1864992

 

select owner,segment_name,segment_type, bytes/1024/1024 "Taille Mo" from (select * from dba_segments where bytes is not null order by bytes desc) where rownum<50;

OWNER      SEGMENT_NAME                   SEGMENT_TYPE        Taille Mo

---------- ------------------------------ ------------------ ----------

VBANK      SAFLIN                         TABLE                   45016

VBANK      SAPRAG                         TABLE                   30927

VBANK      SAFLIN1                        INDEX                    9121

VBANK      SAPRAG3                        INDEX                    5759

VBANK      SAFLIN2                        INDEX                    5027

VBANK      SALPAG0                        INDEX                    4224

VBANK      SALPAG1                        INDEX                    3621

VBANK      SAPRAG0                        INDEX                    3392

VBANK      SAPRAG2                        INDEX                    3328

VBANK      SAFLIN0                        INDEX                    3278

VBANK      SAPRAG1                        INDEX                    3136

VBANK      SALPAG                         TABLE                    3076

VBANK      SAPRTP                         TABLE                    1920

 

Donc 2 solutions au choix pour résoudre ces blocages d’archive logs:

è Changer l’application pour qu’elle diminue ces mises à jours sur ces 3 tables

è Augmenter la place sur disque pour les archive logs de cette instance (disque G :  qui n’a aujourd’hui que 5 go d’espace libre et qui contient essentiellement une partie de la base SRF (39Go) en plus des archiove logs)

 

Coté performance, le 1 octobre toujours , on ne voit pas de SELECT  qui consomme plus d’un centieme de seconde unitairement mais des SELECT en boucle lancées 1 millions de fois dans l’après-midi comme celui-ci :

 

5rxrq8u3ub60q

select /*+ INDEX (SAFLIN SAFLIN2) */ * from SAFLIN where ((((("SOCIET"||"ARRETE")||TO_CHAR("SESSION", 'FM0'))||"IDFLUX")||"CPTEGENE")||TO_CHAR("NUMORD", 'FM00000000'))>:b1 order by ((((("SOCIET"||"ARRETE")||TO_CHAR("SESSION", 'FM0'))||"IDFLUX")||"CPTEGENE")||TO_CHAR("NUMORD", 'FM00000000')) 

Par ailleurs, même s’il n’y a pas de lien avec le blocage des archive logs,  il faudrait réorganiser 2 tables et 3 index afin de gagner environ 20 Go et certainement en performances sur les SELECT de ces tables., il s’agit toujours des tables SAFLIN et SAPRAG :

 

 

Même s’il n’y a pas de lien avec le blocage des archive logs,  il faudrait réorganiser 2 tables et 3 index afin de gagner environ 20 Go et certainement en performances sur les SELECT de ces tables., il s’agit toujours des tables SAFLIN et SAPRAG :

 

OWNER      SEGMENT_NAME  SEGMENT_TYPE       TS         RECLAIM_MB   ALLOC_MB    USED_MB    PCTSAVE RECOMMENDATIONS

---------- ------------- ------------------ ---------- ---------- ---------- ---------- ---------- --------------------------------------------------------------------------------------------

VBANK      SAFLIN        TABLE              VBANK_DATA      12485      45016    32531,1         28 Réorganisez la table VBANK.SAFLIN et effectuez une rÚduction ; pour conomiser 13091404766 octets.

VBANK      SAPRAG        TABLE              VBANK_DATA       8213      30927    22713,9         27 Réorganisez la table VBANK.SAPRAG et effectuez une rÚduction ; pour Úconomiser 8612106675 octets.

VBANK      SAFLIN1       INDEX              VBANK_INDX       1734       9121     7387,2         19 Effectuez une rÚduction ; elle devrait permettre d'Úconomiser 1817969754 octets.

VBANK      SAPRAG3       INDEX              VBANK_INDX       1614       5759       4145         28 Effectuez une rÚduction ; elle devrait permettre d'Úconomiser 1692401890 octets.

VBANK      SALPAG1       INDEX              VBANK_INDX       1068       3621     2553,3         29 Effectuez une rÚduction ; elle devrait permettre d'Úconomiser 1119556557 octets.

                                                                      

Les ordres à passer (dans une fenêtre d’exploitation calme car ils consomment) sont les suivants :

 

alter table VBANK.SAFLIN enable row movement;

alter table VBANK.SAFLIN shrink space;

alter table VBANK.SAFLIN disable row movement;

 

alter table VBANK.SAPRAG enable row movement;

alter table VBANK.SAPRAG shrink space;

alter table VBANK.SAPRAG disable row movement;

 

alter index VBANK.SAFLIN1 shrink space;

alter index VBANK.SAPRAG3 shrink space;

alter index VBANK.SALPAG1 shrink space;

 

Si j’en crois l’activité en MaJ, la meilleure fenêtre serait entre Minuit et 8H00 du matin , cela donne cela en terme de programmation pour cette nuit :

BEGIN

sys.dbms_scheduler.create_job(

job_name => '"SYSTEM"."REORG_SRF"',

job_type => 'PLSQL_BLOCK',

job_action => 'begin

alter table VBANK.SAFLIN enable row movement;

alter table VBANK.SAFLIN shrink space;

alter table VBANK.SAFLIN disable row movement;

alter table VBANK.SAPRAG enable row movement;

alter table VBANK.SAPRAG shrink space;

alter table VBANK.SAPRAG disable row movement;

alter index VBANK.SAFLIN1 shrink space;

alter index VBANK.SAPRAG3 shrink space;

alter index VBANK.SALPAG1 shrink space;

end;',

start_date => '10-oct-2012 00:00:01 am',,

job_class => '"DEFAULT_JOB_CLASS"',

auto_drop => FALSE,

enabled => TRUE);

END;

 

 

 

 

 

 

Oracle signale aussi un probleme de swap sur Joe , je vous laisse regarder :

 

Description: Description: cid:image004.jpg@01CDA88E.FF492AE0

 

 

 

Bonne soirée

Pascal

From: developpeur@client3.com
Sent: mardi 9 octobre 2012 17:07
To: dba@client3.com
Cc: utilisateur@client3.com
Subject: Performances VBank/Oracle

 

Bonjour Jean-Michel,

 

Nous constatons depuis plusieurs mois une dégradation importante des temps de traitements sur notre VBank version Oracle.

 

A titre d’exemple, sur une de nos sociétés, le temps de pré-agrégation (1.400.000 enregistrements traités environ) était de 2h30 jusqu’en avril dernier. Il a progressivement augmenté au fil des mois pour atteindre 4h30 hier.

Cette dégradation est également ressentie par les utilisateurs en mode interactif.

Je vous signale qu’une purge importante a été effectuée en août dernier.

 

Nous nous interrogeons également sur le volume des fichiers audit générés : 6 Go sur la journée d’hier.

 

Nous aimerions que vous interveniez sur notre site afin de nous aider à comprendre les raisons de la dégradation des performances de notre outil VBank.

Merci de nous communiquer vos disponibilités pour cette intervention.

 

Cordialement,

 

Dominique