OLTP/BATCH et bind variables

Bonjour,

je suis nouveau sur le forum et j'espère ne pas aborder un sujet redondant.

Depuis peu, je dois administrer 2 bases Oracle et je débute. Je suis en train d'étudier leurs performances avec Statspack. J'aurais quelques questions à poser, je vous remercie d'avance des réponses et de votre aide:

1) Tous les principaux indicateurs semblent bons. Néanmoins, je me pose une question: En tapant la commande var sous sqlplus, il m'est précisé qu'aucune variable n'est bind. En contre partie, le taux de hard-parses est proche de 0%. Cela voudrait-il dire qu'en l'absence de bind, avec une shared-pool de taille suffisante, ces requêtes théoriquement peu réutilisables pourront l'être et de fait éviter les hard-parses dans mon cas? (je précise que les indicateurs des hard et soft parses sont bons, je cherche juste à trouver des explications aux chiffres avec l'absence de bind variable)

2) J'ai lu que le bind variable était indispensable dans le cadre de traitements OLTP et à proscrire pour des traitements batch. Comment puis-je savoir si je suis dans un cas ou dans l'autre?

3) Statspack me donne une valeur proche de 0% pour les hard parses et de 100% pour les soft parses. A l'inverse, Toad me donne une valeur proche de 50% pour "buffer cache hit ratio". Doit-on tenir compte des indicateurs de Toad ou Statspack est plus fiable?

A bientôt

Désolé mais je trouve tes propos et tes questions assez confuses.

• [1]Pour commencer est ce-que c’est clair pour toi quelle est la différence entre le hard parsing et le soft parsing ?
• [2]C’est plutôt faux
• [3]Est ce-que le « buffer cache hit ratio » est la même chose que les parsings ?

Merci pour ta réponse,

1) pour moi la différence entre le soft et le hard-parsing est le sql reload dans la shared pool pour le hard.

2) mais encore?

3) Tu as raison, je me suis fourvoyé ;) mais je débute sur Oracle et c'est assez tentaculaire... alors je reprends: j'ai un buffer cache hit ratio de 57% sur Toad et un buffer hit de 99% sur Statspack.

1) Je pense que c’est un peu plus compliqué que ça donc je vous invite à approfondir encore le sujet.
2) La question n’est pas batch ou OLTP mais est ce que les avantages et désavantages de chaque situation : noparsing, hardparsing et softparsing sont profitables ou pas ?
3) Il est possible que le rapport du TOAD concerne une session par rapport au statpack qui concerne (très probablement) toutes les sessions. Mais sans les détailles il est difficile à se prononcer.

Merci bien, je vais creuser

Citation:

---

Envoyé par Saperlapon

Merci pour ta réponse,

1) pour moi la différence entre le soft et le hard-parsing est le sql reload dans la shared pool pour le hard.

---

voici un extrait du chapitre Key concepts du livre Troubleshooting Oracle performance de Christian Antognini:

Citation:

---

How Parsing Works
While the previous section described the life cycle of cursors, this section focuses on the parse
phase. The steps carried out during this phase, as shown in Figure 2-2, are the following:

Include VPD predicates: If Virtual Private Database (VPD, formerly known as row-level
security) is in use and active for one of the tables referenced in the parsed SQL statement,
the predicates generated by the security policies are included in its WHERE clause.

Check syntax, semantics, and access rights: This step makes sure not only that the SQL
statement is correctly written but also that all objects referenced by the SQL statement
exist and the current user parsing it has the necessary privileges to access them.

Store parent cursor in library cache: Whenever a shareable parent cursor is not yet available,
some memory is allocated from the library cache, and a new parent cursor is stored inside it.
The key information associated with the parent cursor is the text of the SQL statement.

Logical optimization: During this phase, new and semantically equivalent SQL statements
are produced by applying different transformation techniques. In doing so, the amount of
execution plans considered, the search space, is increased. The purpose is to explore execution
plans that would not be considered without such transformations.

Physical optimization: During this phase, several operations are performed. At first, the
execution plans related to each SQL statement resulting from the logical optimization
are generated. Then, based on statistics found in the data dictionary or gathered through
dynamic sampling, a cost is associated with each execution plan. Lastly, the execution
plan with the lowest cost is selected. Simply put, the query optimizer explores the search
space to find the most efficient execution plan.

Store child cursor in library cache: Some memory is allocated, and the shareable child
cursor is stored inside it and associated with its parent cursor. The key elements associated
with the child cursor are the execution plan and the execution environment.

Once stored in the library cache, parent and child cursors are externalized through the
views v$sqlarea and v$sql, respectively. The cursors are identified in three columns: address,
hash_value, and child_number. With address and hash_value, the parent cursors are identified;
with all three values, the child cursors are identified. In addition, as of Oracle Database 10g, it
is also possible, and it is more common as well, to use sql_id instead of the pair address and
hash_value for the same purpose.

When shareable parent and child cursors are available and, consequently, only the first
two operations are carried out, the parse is called a soft parse. When all operations are carried
out, it is called a hard parse.

---

Je pense que le livre proposé par farenheiit s'adresse à un public avancé, mais je trouve également que son démarche d'indiquer une source fiable d'information est ce qu'il manqué à mes réponses. J'ajoute donc un autre lien vers une des meilleurs sources Oracle Concepts Overview of SQL Processing.

Citation:

---

Envoyé par mnitu

Je pense que le livre proposé par farenheiit s'adresse à un public avancé, mais je trouve également que son démarche d'indiquer une source fiable d'information est ce qu'il manqué à mes réponses. J'ajoute donc un autre lien vers une des meilleurs sources Oracle Concepts Overview of SQL Processing.

---

Pour un développeur ou un DBA qui veut s'interesser aux pb de perfs d'une base de données je pense que ce livre est de loin le meilleur et plutôt simple à lire (comparé au livre de Jonathan LEWIS).
Le chapitre 2 rappelle les concepts clés. le chapitre 6 est absolument fabuleux. je n'ai jamais vu qq'un expliquer aussi bien comment lire un plan d'exécution. J'ai lu le livre 3 fois et à chaque lecture je redécouvre qqchose.

mais bien sûr la base de la base c'est de lire le manuel oracle Database concepts.

Je suis tout à fait d’accord avec vous. Parfois, je le trouve un peu ennuyeux. Mais c’est une excellent référence il n’y a pas de doute.