From: Pascal FAURE
Sent: vendredi 12 octobre 2012 15:38
To:
dba@client3.com
Cc:
developpeur@client3.com;magager@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
Tél : 08 20 22 00 80
Fax 04 76 63 35
37
www.db1.fr
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
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