From: Pascal FAURE
Sent: mercredi 10 octobre
2012 16:35
To: dba@client3.com
Cc: developpeur@client3.com;magager@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 :
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 :
Bonne soirée
Pascal
From: developpeur@client3.com
Sent: mardi 9 octobre 2012 17:07
To: dba@client3.com
Cc: manager@client3.com;utilisateur@client3.com
Subject: Performances VBank/Oracle
Bonjour
Monsieur Le Guern,
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