IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Combien votre base de données contient-elle de tables avec plus de 20 colonnes ? (une seul choix pos

Votants
40. Vous ne pouvez pas participer à ce sondage.
  • Moins de 5%

    24 60,00%
  • Moins de 10%

    4 10,00%
  • Moins de 20%

    5 12,50%
  • PLUS de 20%

    7 17,50%
Optimisations SGBD Discussion :

Petites tables ou grandes tables. . . Quelles conséquences sur les performances ?


Sujet :

Optimisations SGBD

  1. #61
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Encore une fois vous vous focalisez tous sur les lectures, alors que ces dernières peuvent être non verrouillantes (mode READ UNCOMMITED ou SNAPSHOT).
    Ce qui pose problème c'est bien plus les accès concurrent en écriture dans une seule et même table !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  2. #62
    Membre émérite Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Points : 2 845
    Points
    2 845
    Par défaut
    Sur une seule et même table ou sur une seule et même ligne ?

    Dans le premier cas, ça ne concerne encore une fois que SQL Server..
    En tous cas sous Oracle, dans le cas général, une modification d'une ligne ne lock que cette ligne...

    (c'est ma photo)
    Paku, Paku !
    Pour les jeunes incultes : non, je ne suis pas un pokémon...

    Le pacblog : http://pacmann.over-blog.com/

  3. #63
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par pacmann Voir le message
    ... En tous cas sous Oracle, dans le cas général, une modification d'une ligne ne lock que cette ligne...
    Avec DB2 for z/OS, on choisit la granularité du verrouillage (ligne, page ou table) avec souvent une préférence pour la page.

    Dans un contexte de forte concurrence que sont les systèmes OLTP sur Mainframe, il ne viendrait à l'idée de personne de verouiller la table en mise à jour pour un seul processus ...

  4. #64
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Vouloir tout mettre dans le minimum de tables et se retrouver avec un maximum de colonnes par table est évidemment la source de tous les ennuis (obésité, multiplicité des index (pensons aux conséquences des mises à jour...), mauvaise performance (y-compris pour les tâches de service : réorganisations, sauvegardes, j’en passe et des meilleures), redondances, incohérences, contentions, etc.) Pour assurer le coup, bannissons les « groupes répétitifs » et tant qu’à faire, normalisons au moins en 4NF, là au moins on est sûr de multiplier les tables de peu de colonnes, avec moins d’encombrement, de redondance, de perte de temps en mise à jour, on gagnera en cohérence, on économisera les ressources, etc.


    Citation Envoyé par Luc Orient Voir le message
    Avec DB2 for z/OS, on choisit la granularité du verrouillage (ligne, page ou table) avec souvent une préférence pour la page.

    Dans un contexte de forte concurrence que sont les systèmes OLTP sur Mainframe, il ne viendrait à l'idée de personne de verrouiller la table en mise à jour pour un seul processus ...
    Je confirme !


    Citation Envoyé par SQLpro Voir le message
    Pour le ROWID...
    Citation Envoyé par Luc Orient Voir le message
    il semble que SQL Server ait fait le choix curieux de stocker la clé primaire comme référence à la ligne dans les index secondaires ...
    Ce choix n'est pas curieux il est même très intéressant, c'est la notion d'index cluster...
    Effectivement tous les index non cluster reposent sur la valeur de la clef de l'index cluster pour retrouver la ligne originale.
    C’est le concept d’index cluster façon SQL Server. Chaque SGBD voit le clustering à sa façon. On a déjà évoqué le sujet ici ou à propos des soixante-sept millions de bovins chers à CinePhil.

    Permettez-moi de me citer :

    Citation Envoyé par fsmrel Voir le message
    Si j’ai bien compris, et pour résumer : physiquement parlant, avec SQL Server, les données d’une table sont intégrées à l’index cluster, dont elles constituent le niveau feuilles. A cette occasion et par comparaison, je rappelle qu’avec DB2, la table est hébergée dans un table space à part. Reprenons le cas de la recherche d’une vachette. Si l’on effectue un accès selon la séquence cluster, tout le monde a bon, en quatre entrées/sorties (symbolisées par des flèches rouges) on récupère les données de Zaza parmi soixante-sept millions de bovins :


    Citation Envoyé par fsmrel
    So far, so good. Si l’on effectue maintenant une recherche qui ne met pas directement en jeu l’index cluster, la stratégie n’est plus la même, cf. figure B ci-dessous. Dans tous les cas, le SGBD utilise les services de l’index non cluster qui va bien (s’il existe). Dans un cas, les feuilles de cet index adressent la racine de l’index cluster et dans l’autre cas directement le table space hébergeant la table, d’où un nombre d’entrées/sorties (ou de cailloux pour le Petit Poucet) égal à 8 dans un cas et à 5 dans l’autre cas (avec en l’occurrence un gain en I/O time plus que substantiel, conséquence du court-circuit de l’index cluster).


    Citation Envoyé par fsmrel
    Est-ce bien cela ? Si ce n’est pas le cas, je referai les dessins.
    Si quelqu'un avait la bonté de confirmer ou infirmer...


    Citation Envoyé par SQLpro Voir le message
    Cela permet beaucoup de choses, comme par exemple en cas de défragmentation de la table, ne pas toucher aux index !
    On en a parlé ici et ce problème a toujours fait l’objet des plus grands soins de la part des SGBD, même bien avant l’arrivée des SGBD relationnels. Par exemple, ADABAS avec ses ISN numbers (~ RID) était exemplaire à ce sujet.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #65
    Membre émérite Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Points : 2 845
    Points
    2 845
    Par défaut
    Salut,

    C'est exactement ce que j'essayais de dire... mais c'est vraiment mieux avec les dessins

    Et pour refaire un peu de pub, sous Oracle, tu peux choisir si tu veux le modèle SQL Server (Organization = index) ou DB2 (Organization = heap).

    (c'est ma photo)
    Paku, Paku !
    Pour les jeunes incultes : non, je ne suis pas un pokémon...

    Le pacblog : http://pacmann.over-blog.com/

  6. #66
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Merci François de m'avoir raffraichi la mémoire sur ce vieux cours que tu avais donné lorsque je travaillais sur les bovins. On peut dire que j'avais carrément tout oublié !

    Il reste cependant des points obscur mais je ne suis pas sûr que ce soit le lieu pour les aborder.

    En fait, il faudrait carrément faire un article sur le fonctionnement des index dans les SGBD mais je n'ai pas le temps de m'y coller. En plus, je ne pourrais pas faire ça tout seul vu mon peu de connaissances en ce domaine.

    Mais si quelqu'un veut lancer le projet, qu'il ne se gène pas !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #67
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 811
    Points
    17 811
    Par défaut
    Citation Envoyé par pacmann Voir le message
    Et pour refaire un peu de pub, sous Oracle, tu peux choisir si tu veux le modèle SQL Server (Organization = index) ou DB2 (Organization = heap).
    C'est pareil chez la concurrence, sur SQL-Server aussi tu peux choisir d'avoir des index cluster ou non cluster.

  8. #68
    Membre émérite Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Points : 2 845
    Points
    2 845
    Par défaut
    Ho, c'était donc ça...

    Citation Envoyé par Waldar Voir le message
    là où SQL-Server le propose quasiment par défaut.

    (c'est ma photo)
    Paku, Paku !
    Pour les jeunes incultes : non, je ne suis pas un pokémon...

    Le pacblog : http://pacmann.over-blog.com/

  9. #69
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 811
    Points
    17 811
    Par défaut
    Tout est dans le quasiment !

  10. #70
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Si quelqu'un avait la bonté de confirmer ou infirmer...
    je te confirme....

    Mais je rajouterais deux choses :
    1) on n'est pas obligé de créer un index clustered sur chaque table dans MS SQL Server, même si c'est une bonne pratique.
    2) il faut bien choisir son index cluster si l'on doit en implanter un : le plus petit possible, avec le plus grand nombre de valeur possible, invariant et si possible monotone en sus d'être UNIQUE. Bref, l'auto incrément ou un horodatage en PK est parfait
    3) dans les SGBDR on s'aperçoit que les données les plus utilisées sont (à différentes échelles, mais c'est quasiment TOUJOURS vrai) les plus récentes :
    • pour les commandes, facture, bons de livraisons c'est extrêmement vrai
    • pour les produits c'est assez vrai (pense au téléviseur noir et blanc à tube cathodique),
    • pour les clients c'est aussi relativement vrai (un client d'il y a 10 ans à plus de chance d'être mort qu'un client qui viens tout juste d'être saisi.)

    Or l’organisation d'une table en cluster avec un auto incrément ou un horodatage maximise la mise en cache des données les plus fréquemment scrutées puisqu'elle regroupe dans les mêmes pages les données les plus récentes... alors que pour une table en HEAP ce n'est jamais le cas.... ce qui oblige à farcir la mémoire de pages sous utilisées (et conduit donc à une durée de vie des pages en mémoire bien moins longues..., donc du Roll Over, donc des temps de réponse globalement moins bon !!!)

    Bref, il n'y a pas que le nombre de page a lire qui a son importance !

    Comme tu le sais, le système est global (théorie des systèmes) et le voir par un seul bout de la lorgnette peut s'avérer casse gueule !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #71
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par SQLpro Voir le message
    je te confirme...
    Merci...


    Citation Envoyé par SQLpro Voir le message
    il n'y a pas que le nombre de pages à lire qui a son importance !
    On est bien d’accord. Lire un maximum de pages dans un minimum de temps est une excellente chose, mais si c’est ce qui est lu est faux, on a tout perdu.

    Mais inversement, avec des données saines, s’il faut dix jours pour effectuer un batch quotidien sensible (j’ai eu à auditer et réparer ça...) parce qu’il y a des I/O bound dans tous les sens, ça n’est pas mieux (voir « Le clustering selon DB2 for z/OS », plus précisément la partie « Le rôle crucial de l'index cluster. I/O bound vs CPU bound »).

    Les données ne sont pas forcément toutes présentes en mémoire, et les performances désastreuses qui sont la conséquence des I/O bound incitent à faire en sorte que les index cluster de deux tables (et plus) à joindre soient synchrones pour éliminer ce phénomène.

    Je suis évidemment d'accord que les données les plus utilisées sont les plus récentes et qu’en conséquence l’auto-incrément ou un horodatage pour une clé primaire est une bonne chose (avec un bémol si les INSERT provoquent des phénomènes de verrouillage) parce que cela évacue efficacement les I/O bound lorsqu’on exécute des SELECT.

    Cela dit, il y a des situations dans lesquelles on peut avoir intérêt à ce que les lignes d’une table qui sont chronologiquement consécutives soient en fait éparpillées dans l’espace (façon puzzle bien sûr). Si une foule d’utilisateurs saisissent des commandes en même temps, il y aura risque de contention impliquant les tables des commandes et des lignes de commande, conséquence du mécanisme de verrouillage (je parle pour DB2 for z/OS où, comme le rappelle Luc Orient, on privilégie plutôt le verrouillage au niveau page, sachant que je ne connais pas les usages avec SQL Server...). Que les valeurs de la clé primaire de la table des clients soient hachées plutôt qu’incrémentées ne me gêne pas, au contraire, car les risques de contention en cas de mise à jour des clients deviennent très minimes (création, modification, suppression). En revanche, le hachage des valeurs prises par la clé de la table des commandes et de celle de la table des lignes de commande n’est évidemment pas recommandé, car si les risques de contention disparaissent les I/O bounds ne manqueront alors pas de se manifester en masse...

    C’est là où la soute et la dunette se rejoignent : une des clés de la performance des applications est liée à l’utilisation de l’identification relative au niveau conceptuel (disons MCD Merise). Dans la soute, si en conséquence la clé (hachée) de la table des clients est le singleton {CliId}, celle de la table des commandes est composée du couple {CliId, CdeId}, celle de la table des lignes de commande est composée du triplet {CliId, CdeId, LigneId}, celle de la table des engagements sur ligne de commande est composée du quadruplet {CliId, CdeId, LigneId, EngId}, etc., façon poupées russes, alors les I/O bounds et les contentions seront absents, si pour chacune de ces tables la clé de l’index cluster est celle de la clé de la table.

    Si l’on souhaite savoir quels camions livrent le client untel (cf. Dénormalisation vs amélioration (optimisation), le 4e exemple et la note concernant l’identification relative), grâce à l’identification relative répercutée sur le clustering, non seulement on élimine le phénomène d’I/O bound, mais en plus on élimine des jointures qui, si on utilisait l’identification absolue seraient inévitables (2 jointures contre 5 dans l’exemple).

    Pour une entreprise dans laquelle les traitements qui tournent autour des commandes sont ceux qui méritent la plus grande attention, la mise en œuvre de l’identification relative associée au clustering aura un impact déterminant. La stratégie est du reste la même si l’on traite des appels de cotisation dans les caisses de retraite ou autres organismes, etc.

    Il est évident que toutes les requêtes ne peuvent pas bénéficier de ce traitement de faveur, et qu’il restera des I/O bound quelque part. Néanmoins, lors de l’étape de conception, suite aux entretiens avec la maîtrise d’œuvre et les chefs de projets, en tant que DBA on sait quand même quelles seront les requêtes les plus fréquentes, les plus sensibles, celles qui si on n’y prend pas garde feront que les applications partiront en vrille (j’en reviens au batch lourd quotidien qui a duré dix jours lors de sa mise en production (sur une machine bases de données à cent-vingt-huit millions de francs à l’époque, et qui n’avait bien entendu jamais fait l’objet du moindre prototypage de performances...).


    Citation Envoyé par SQLpro Voir le message
    Comme tu le sais, le système est global (théorie des systèmes) et le voir par un seul bout de la lorgnette peut s'avérer casse gueule !
    Don’t worry! La théorie c'est bien, mais la pratique c'est pas mal non plus. Ça fait quarante cinq ans que la validité des données, la performance des applications et la satisfaction de mes clients font partie de mes préoccupations...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  12. #72
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Note bien que tout ceci est en train de se remettre en cause notamment avec les SSD qui, agrégés sous forme RAID, donnent parfois des résultats spectaculaires...

    Pour ce qui est de SQL Server, cela fonctionne de même (préférence au verrouillage page, mais descente à la ligne en cas de concurrence).

    Pour ce qui concerne le hot spot de calcul des clefs auto incrémentées dans SQL Server, il a fait l'objet d'une excellente optimisation, mais au prix d'un bug rarissime, mais néanmoins gênant : celui de doublons (évidemment rejetés s'il y a contrainte PK ou UNIQUE).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #73
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par SQLpro Voir le message
    Pour ce qui est de SQL Server, cela fonctionne de même (préférence au verrouillage page, mais descente à la ligne en cas de concurrence).
    Qui détermine la préférence ? Le DBA ? SQL Server ?
    Si le granule de verrouillage est la page, et s’il y a de la concurrence en mise à jour, SQL Server prend-il dynamiquement l’initiative de passer au verrouillage au niveau de la ligne, quitte à revenir plus tard à la page (en supposant qu'il sache inférer que ça vaut le coup) ?

    D'après ce que je lis dans la doc, le SGBD se baserait plutôt sur les caractéristiques du schéma et des requêtes :
    The Database Engine automatically determines what locks are most appropriate when the query is executed, based on the characteristics of the schema and query.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  14. #74
    Rédacteur/Modérateur

    Avatar de Fabien Celaia
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2002
    Messages
    4 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Service public

    Informations forums :
    Inscription : Octobre 2002
    Messages : 4 220
    Points : 19 546
    Points
    19 546
    Billets dans le blog
    25
    Par défaut
    Il y a une notion d'escalade de verrouillage, faite par le moteur.

    A un certain seuil (à l'époque éculée de mes derniers cours Internals, c'était 200 pages), le verrouillage page passe à un verrouillage table.

    Visiblement, [source], les seuils ont changé mais le principe est resté au travers des ans...

    On peut bien sûr forcer cela, si l'on se croit plus malin que lui .

    Sr DBA Oracle / MS-SQL / MySQL / Postgresql / SAP-Sybase / Informix / DB2

    N'oublie pas de consulter mes articles, mon blog, les cours et les FAQ SGBD

    Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !

  15. #75
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Yanika_bzh Voir le message
    Par exemple une voiture :

    Année Production
    Poids
    Répartition AV/AR (kg)
    Longueur
    Largeur
    Hauteur
    Empattement
    Jantes
    Pneumatique
    Type (Nb Cylindres)
    Position
    Materiaux (Culasse/Bloc)
    Nombre de soupapes par cylindre
    Distribution
    Alimentation allumage
    Suralimentation
    Cylindrée (Cm3)
    Alésage x course (mm)
    Rapport Volumétrique
    Régime Maximum (tr/min)
    Puissance Maxi (ch à tr/min)
    Puissance au litre (ch)
    Couple maxi (mkg a tr/min)
    Couple au litre (mkg)
    Boite de vitesse
    Nombre de vitesse
    Transmission
    suspension Avant
    Suspension Arriere
    Direction
    Type de Freins
    Diametres des Freins (mm
    Etrier
    Piston

    non ?
    NON !!! Vous avez supposé stupidement que votre voiture avait un moteur thermique. Un bon nombre de caractéristique ne sont pas de la voiture, mais d'une partie de la voiture appelé moteur. Vous allez donc violer la première forme normale par le fait que pour la Tesla par exemple, beaucoup de colonnes vont être nulles alors qu'elle devraient avoir une valeur atomique !

    Il faut donc décomposer en moteur, châssis, transmission....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #76
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par nathalie.laudun Voir le message
    Ca m'a l'air bien théorique et bien coloré "noir ou blanc"... Ou bien on est "normalisé" ou bien on met "tout dans une seule table"... Un peu exagéré comme commentaire, non?

    Si on parle Oracle, je ne vois pas comment joindre des tables de millions de lignes ne coûte "presque rien".
    C'est l'exemple qui masque la forêt...
    Vous allez un petit peu gagner en lecture et perdre énormément en écriture. Or les lectures peuvent être faite en // mais pas les écritures :
    • soit verrouillage pessimiste => temps d'attente du fait des blocages
    • soit verrouillage optimiste => multiplication des ressources du fait du versionning plus conséquent + perte de mise à jour en finalité de transaction plus fréquent.



    Donc, vous êtes un peu gagnant, mais très perdant, sauf si votre base de données est statique (cas de l'OLAP).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  17. #77
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par pacmann Voir le message
    Et cela permet donc de devoir toujours faire deux accès index au lieu d'un quand tu ne recherches pas sur la PK ?
    Cool !
    Non, car SQL Server permet des index couvrants par le biais de la clause INCLUDE qu'aucun autre SGBDR ne propose et qui permettent de ne plus lire la table du tout.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  18. #78
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par pacmann Voir le message
    Sur une seule et même table ou sur une seule et même ligne ?

    Dans le premier cas, ça ne concerne encore une fois que SQL Server..
    En tous cas sous Oracle, dans le cas général, une modification d'une ligne ne lock que cette ligne...
    Mais c'st la même chose dans presque tous les SGBDR ! => SQL Server, IBM DB2... Réveillez vous, allez voir la concurrence, ne vous focalisez pas sur Oracle !!!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  19. #79
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Si quelqu'un avait la bonté de confirmer ou infirmer...
    Je confirme et j'infirme !

    En effet, si vous ne faite que des index classiques, alors une colonne ne figurant pas dans la clef (à l'exception de celle(s) concernant la clef de l'index clustered) oblige à une double lecture.
    MAIS...
    SQL Server propose depuis 10 ans, la clause INCLUDE qui permet de rajouter dans l'index non clustered, toutes les colonnes que l'on souhaite afin de rendre l'index couvrant pour la requête...
    Dans ce cas, SQL Server sera encore plus rapide que Oracle ou DB2 puisqu'une seule recherche dans l'index donne l'intégralité des informations nécessaire à la requête.

    Syntaxe :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CREATE INDEX <nom_index> 
       ON <nom_table> (<clef_index>)
       INCLUDE (<liste_colonnes_en_sus>);
    Les colonnes figurant dans la <liste_colonnes_en_sus>, ne sont pas indexées. Elle sont uniquement présente au niveau feuille et peuvent être parcourues par un CAN en plus du SEEK des pages de navigation du BTree+



    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  20. #80
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 269
    Points
    38 269
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Waldar Voir le message
    Bon article, j'y mettrai deux bémols dont on peut discuter.

    Les verrous
    Avec Oracle, un verrou exclusif ne bloque que la ligne en écriture, pas toute la table. On peut toujours lire la table, insérer de nouvelles données, mettre à jour des données sur d'autres lignes.
    Donc ce n'est pas pénalisant outre mesure.
    C'est vrai aussi avec d'autres SGBD
    DB2 for Z/OS par exemple permet de choisir la taille du verrou, le verrou ligne est l'une des options possibles

    Il n'en reste pas moins que si l'on a mal modélisé, comme dans l'exemple où les numéros de téléphones sont présents dans la table des signalétique individu , on verrouille les données de toute la ligne et donc à la fois la signalétique (nom, prénom...) et les numéros de téléphone, ce qui ne se produit pas avec une modélisation normalisée

Discussions similaires

  1. Impact sur les performances avec un grand nombre de tables
    Par enila dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 04/08/2011, 16h40
  2. Une grande table VS 2 tables de taille correcte
    Par mikaeru dans le forum Optimisations
    Réponses: 3
    Dernier message: 11/06/2011, 17h17
  3. [AC-2003] séparer une grande table en sous table par année
    Par MatAir dans le forum Requêtes et SQL.
    Réponses: 1
    Dernier message: 25/03/2011, 20h24
  4. Réponses: 3
    Dernier message: 04/01/2011, 16h05
  5. Impact sur les performances d'un grand nombre de tables
    Par thechief dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 16/07/2010, 17h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo