Discussion :

[lboutet]

Bonjour,

J'aurais besoin de conseils/d'avis concernant une petite problématique.
Chez mon client, je dois lancer via un script environ 800 instructions "alter table...drop column...", 800 instructions "delete from..." et 800 instructions "insert into...".
Dans nos tests, on s'aperçoit que si on lance ces 2400 instructions, la mémoire augmente pas mal (20% de plus) sans retomber, même 1h après.

D'après vous, serait-il possible de minimiser cette utilisation mémoire ? Ou de faire quelque chose pour la faire retomber ?
Bien entendu (sinon ce serait trop simple ), je n'ai pas la possibilité d'arrêter et de redémarrer la BDD

Merci pour vos avis éclairés

Bonne journée

[Ikebukuro]

Salut,
J'aimerais beaucoup savoir quels sont les tests (SELECTs) que vous lancez pour vérifier l'augmentation de la mémoire et quels sont les résultats obtenus.
Avec ça on comprendra mieux ce qui se passe.

[vanagreg]

Bonjour,

Je doute que tu aies besoin d'énormément de mémoire pour faire ces opérations. Est-ce que tu fais du BULK COLLECT pour tes inserts/deletes par hasard?
Au fait pourquoi vouloir redémarrer l'instance Oracle, ce n'est pas un PC Windows!

[lboutet]

Alors, je viens d'avoir accès au serveur de test...finalement en Oracle 11.2.0.4...
Quelques résultats :

select * from v$version;
 
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE	11.2.0.4.0	Production
TNS for 64-bit Windows: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

===============================================================
show parameter sga
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 1648M
sga_target                           big integer 0

===============================================================
show parameter pga
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 0

===============================================================

Pour la mémoire, comparaison avant/après, cf. fichiers joints :
01_Mémoire_Avant.txt
01_Mémoire_Après.txt

Merci encore

[vanagreg]

Tu dois être en gestion automatique (paramètre memory_target renseigné). Je vois SGA_MAX_SIZE 1.6Go. Même sur ma base perso de mon PC portable j'ai plus que ça.

[Ikebukuro]

Pour les deux fichiers joints, cela eut été mieux de faire un order by desc sur BYTES car là on ne voit pas facilement les changements.

[lboutet]

Quand on regarde la mémoire utilisée dans le "Task Manager" de Windows, pour le process Oracle RDBMS Kernel Executable, avant les opérations on a : 541.3 MB
Et juste après les opérations on a 1135.3 MB

Et ça ne veut pas baisser...

J'ai tenté
- alter system flush buffer_cache
- alter system flush shared_pool

Mais ça ne change rien...

Si je redémarre ma BDD, le process Oracle RDBMS Kernel Executable reste bien bas à un peu moins de 400 MB

Du coup...y aurait-il d'autres lignes de commande qui me permettrait de faire baisser cette mémoire "à chaud" ?

Après, Oracle gère sa mémoire ok...mais bon, aux yeux du client, d'un coup on lui fait "perdre" 20% de sa mémoire pour une petite opération, pas facile à faire avaler la pilulle

[Waldar]

Je ne comprends pas un client qui pinaille pour 1 Go de RAM.
Le coût relatif au temps que vous avez passé à créer ce post et à répondre aux questions vous auriez pu acheter 32 Go de plus, facile.

[vanagreg]

Quel est le pb au juste? La SGA max c'est 1.6Go. Si le client veut moins alors il peut baisser les paramètres liés à la mémoire. Mais là je pense qu'il chipote pour pas grand chose. En plus je suis pas certain que Windblows n'y mette pas son grain de sel dans la gestion du processus.

[Ikebukuro]

Effectivement, 1.6Go de RAM c'est... plus que ridicule en 2021. 4Go me semble un minimum aujourd'hui.
La base est une base de prod, de recette...?


Ah, au fait, la version d'Oracle de ton client n'est pas une version Entreprise. Un client qui pinaille pour si peu de RAM n'a pas d'argent et donc il ne paiera pas une licence Oracle. Sa version est moins performante dans la gestion des ressources.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
select * from v$version;
-- ta version, le mot clé Entreprise est absent.
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
...
 
-- une version Entreprise, avec le mot clé présent.
select * from v$version;
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

Si c'est une base de prod ou toute base avec beaucoup de personnes connectées, évite au maximum ces deux opérations car elles vont considérablement ralentir la base.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
alter system flush buffer_cache
alter system flush shared_pool

[SQLpro]

Quand on regarde la mémoire utilisée dans le "Task Manager" de Windows, pour le process Oracle RDBMS Kernel Executable, avant les opérations on a : 541.3 MB
Et juste après les opérations on a 1135.3 MB
...
Si je redémarre ma BDD, le process Oracle RDBMS Kernel Executable reste bien bas à un peu moins de 400 MB
Du coup...y aurait-il d'autres lignes de commande qui me permettrait de faire baisser cette mémoire "à chaud" ?

Pour aller vite, un SGBD Relationnel travaille ses données exclusivement en RAM, pas en lisant les disques. Si les données ne sont pas en mémoire il les y met en montant les données du disque en mémoire, pus en exécutant la requête en mémoire (pour simplifier).
Le temps d'accès moyen d'un disque est de l'ordre de 10 ms (disque magnétique) ou 1 ms (SSD). Le temps de scrutation de la mémoire c'est 10 nano secondes, soit un écart intrinsèque de l'ordre de 1 000 000 ! (en fait avec la circulation dans les bus, le différentiel est de l'ordre de 10 000, autrement dit une lecture en mémoire est dix mille fois plus rapide que sur disque...).
Une fois les données montée en mémoire elles y persiste aussi longtemps que possible pour éviter des temps de réponse dégueulasse... Tout simplement parce que ces données ont toutes les chances de devoir être réutilisées tôt ou tard.

Si cela ne vous convient pas et que vous voulez absolument minimiser la mémoire et par conséquent avoir des temps de réponse dégueulasse, vous devriez redévelopper cette application à base de fichiers séquentiel indexé avec du COBOL.... Vous feriez beaucoup d'économie, pas seulement de mémoire, sachant qu'une licence basique pour Oracle c'est quelques dizaines de milliers d'euros !

A +

[lboutet]

Merci à tous, je passe mon sujet à résolu...le client fera avec, je suis bien d'accord avec toutes vos remarques