Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur PK clustered hors du groupe primary ?

PK clustered hors du groupe primary ?

9 réponses
Avatar
Timur
Bonjour,

dans entreprise manager, il n'est pas possible de creer une clé CLUSTERED
dans un groupe différent de celui des données de la table (choix grisé).
J'ai lu pas mal de choses à ce propos, et j'ai bien compris pourquoi.


Néanmoins, le script :

CREATE TABLE dbo.MATABLE (
ID int NOT NULL IDENTITY (1, 1),
valeur varchar(200) NULL
) ON MATABLE_data
GO

ALTER TABLE dbo.MATABLE
ADD CONSTRAINT PK_MATABLE PRIMARY KEY CLUSTERED
(
ID
) ON MATABLE_ind


fonctionne, alors que la PK clustered est dans un autre groupe.

Alors, c'est possible ou pas ?




--
Cordialement
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrice
A priori (vu dans la doc du ALTER TABLE) :

"Si l'option ON est spécifiée lors de la création d'un index ordonné en
clusters pour une contrainte PRIMARY KEY ou UNIQUE, la table dans son
intégralité est placée dans le groupe de fichiers spécifié lorsque l'index
ordonné en clusters est créé."

--
Patrice

"Timur" a écrit dans le message de
news:
Bonjour,

dans entreprise manager, il n'est pas possible de creer une clé CLUSTERED
dans un groupe différent de celui des données de la table (choix grisé).
J'ai lu pas mal de choses à ce propos, et j'ai bien compris pourquoi.


Néanmoins, le script :

CREATE TABLE dbo.MATABLE (
ID int NOT NULL IDENTITY (1, 1),
valeur varchar(200) NULL
) ON MATABLE_data
GO

ALTER TABLE dbo.MATABLE
ADD CONSTRAINT PK_MATABLE PRIMARY KEY CLUSTERED
(
ID
) ON MATABLE_ind


fonctionne, alors que la PK clustered est dans un autre groupe.

Alors, c'est possible ou pas ?




--
Cordialement






Avatar
Timur
Merci Patrice...

Comme quoi on ne lit jamais assez la doc... mea culpa !

En tout cas, ca fait un peu peur (et ça peut réserver des surprises
désagréables !) de voir que les datas sont déplacées sans autre forme de
procès !

merci

--
Cordialement

Omnia vanitas


"Patrice" a écrit dans le message de
news:
A priori (vu dans la doc du ALTER TABLE) :

"Si l'option ON est spécifiée lors de la création d'un index ordonné en
clusters pour une contrainte PRIMARY KEY ou UNIQUE, la table dans son
intégralité est placée dans le groupe de fichiers spécifié lorsque l'index
ordonné en clusters est créé."

--
Patrice

"Timur" a écrit dans le message de
news:
> Bonjour,
>
> dans entreprise manager, il n'est pas possible de creer une clé


CLUSTERED
> dans un groupe différent de celui des données de la table (choix grisé).
> J'ai lu pas mal de choses à ce propos, et j'ai bien compris pourquoi.
>
>
> Néanmoins, le script :
>
> CREATE TABLE dbo.MATABLE (
> ID int NOT NULL IDENTITY (1, 1),
> valeur varchar(200) NULL
> ) ON MATABLE_data
> GO
>
> ALTER TABLE dbo.MATABLE
> ADD CONSTRAINT PK_MATABLE PRIMARY KEY CLUSTERED
> (
> ID
> ) ON MATABLE_ind
>
>
> fonctionne, alors que la PK clustered est dans un autre groupe.
>
> Alors, c'est possible ou pas ?
>
>
>
>
> --
> Cordialement
>
>
>
>




Avatar
Fred BROUARD
bonjour

Timur a écrit:
Merci Patrice...

Comme quoi on ne lit jamais assez la doc... mea culpa !

En tout cas, ca fait un peu peur (et ça peut réserver des surprises
désagréables !) de voir que les datas sont déplacées sans autre forme de
procès !



Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de type CLUSTER !!!
Un index cluster contient TOUTE la table.
Un index cluster est constitué par les lignes de la table physiquement ordonnés
dans le sens de la clef.
Déplacer un index cluster revient à déplacer la table.

A +


merci




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Lionelp
Bonjour,

En plus de ce que dit Fred, il n'est pas conseillé de mettre les index dans
des file groups spécifiques car la contention va se reporter sur ce ou ces
file groups. On conseille de créer plusieurs data files pour le file group
par défaut de cette manière les IO seront répartis de manière égale sur les
différent data files.
On crée un ou des file group(s) pour une ou plusieurs tables pour des soucis
d'administration ou de découpage logique lorsque l'on a besoin de pouvoir
restorer un file group ou une table.

Cordialement,
LionelP

"Fred BROUARD" a écrit :

bonjour

Timur a écrit:
> Merci Patrice...
>
> Comme quoi on ne lit jamais assez la doc... mea culpa !
>
> En tout cas, ca fait un peu peur (et ça peut réserver des surprises
> désagréables !) de voir que les datas sont déplacées sans autre forme de
> procès !

Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de type CLUSTER !!!
Un index cluster contient TOUTE la table.
Un index cluster est constitué par les lignes de la table physiquement ordonnés
dans le sens de la clef.
Déplacer un index cluster revient à déplacer la table.

A +

>
> merci
>

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************




Avatar
Timur
Bonjour,

A Fred :
Merci pour ces précisions même si le ton est toujours aussi ... direct.
J'avais bien compris que pour un index cluster les données sont la table
elle-même. Il y a néanmoins bien des pages d'index, non ? Bon, SQL 2k ne
permet pas de séparer ces pages d'index des feuilles du b-tree clustered,
c'est sa conception des choses. C'est géré de façon différente par d'autres
SGBD.

A Lionel :
J'ai appris qu'il pouvait être important de séparer les datas et les index
sur des disques différents. Si on a plusieurs datafiles, SQL va les remplir
chacun au fur et à mesure, ou bascule du premier vers le second quand
celui-ci est plein ? Je ne comprend pas trop pourquoi il y aurait un
problème de contention au niveau d'un groupe d'index.


--
Cordialement

Omnia vanitas


"Lionelp" a écrit dans le message de
news:
Bonjour,

En plus de ce que dit Fred, il n'est pas conseillé de mettre les index


dans
des file groups spécifiques car la contention va se reporter sur ce ou ces
file groups. On conseille de créer plusieurs data files pour le file group
par défaut de cette manière les IO seront répartis de manière égale sur


les
différent data files.
On crée un ou des file group(s) pour une ou plusieurs tables pour des


soucis
d'administration ou de découpage logique lorsque l'on a besoin de pouvoir
restorer un file group ou une table.

Cordialement,
LionelP

"Fred BROUARD" a écrit :

> bonjour
>
> Timur a écrit:
> > Merci Patrice...
> >
> > Comme quoi on ne lit jamais assez la doc... mea culpa !
> >
> > En tout cas, ca fait un peu peur (et ça peut réserver des surprises
> > désagréables !) de voir que les datas sont déplacées sans autre forme


de
> > procès !
>
> Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de type


CLUSTER !!!
> Un index cluster contient TOUTE la table.
> Un index cluster est constitué par les lignes de la table physiquement


ordonnés
> dans le sens de la clef.
> Déplacer un index cluster revient à déplacer la table.
>
> A +
>
> >
> > merci
> >
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
>


Avatar
Fred BROUARD
Timur a écrit:
Bonjour,

A Fred :
Merci pour ces précisions même si le ton est toujours aussi ... direct.
J'avais bien compris que pour un index cluster les données sont la table
elle-même. Il y a néanmoins bien des pages d'index, non ?



Oui et non. Il y a bien des pages de noeuds d'index, mais aucune feuille d'index
puisque à ce niveau on trouve la ligne de la table. Et pour des performances il
faut que cela soit indisociable sinon on perd tout le bénéfice de l'index cluster.

Bon, SQL 2k ne
permet pas de séparer ces pages d'index des feuilles du b-tree clustered,
c'est sa conception des choses.



Cela n'a pas de sens !

C'est géré de façon différente par d'autres
SGBD.



Je serais curieux de connaître les SGBDR qui réalisent des index cluster dans
lesquelles les noeuds intermédiaires sont séparés ou séparable des feuilles !


A Lionel :
J'ai appris qu'il pouvait être important de séparer les datas et les index
sur des disques différents.



Oui, mais l'index cluster contient TOUTES les données de la table. Autrement dit
l'index cluster est la table + quelques noeuds d'index intermédiaire.

Si on a plusieurs datafiles, SQL va les remplir
chacun au fur et à mesure, ou bascule du premier vers le second quand
celui-ci est plein ?



Pas l'un après l'autre ! Il va les remplir de manière équilibré de façon à
paralléliser les accès et les écritures et cela pour des raisons de perf. De
même pour les sauvegardes multifichiers etc...

Je ne comprend pas trop pourquoi il y aurait un
problème de contention au niveau d'un groupe d'index.



Si tu t'intéresse à ce genre de choses, miaux vaudrait que tu suive une
formation. Par exemple celle de Learning Tree que je vais dispenser à Toulosue
par exemple dans 15 jours :
http://www.learningtree.fr/courses/535qa.htm

A +






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
lionelp
Bonjour,

Si j'ai compris la remarque sur séparation data et index alors elle est
incorrecte.
Si j'ai plusieurs data files dans mon file group alors SQL Server va
paralléliser les IOs et les data files vont se remplir de manière égale ou à
peu près.
Si j'ai 1 filegroup pour les data et 1 pour les index je vais concentrer la
contention sur le filegroup des index car les data sont généralement accédées
à l'aide des index. Ou bien je fais un table scan et je n'utilise que le
filegroup des data au lieu des 2.
A lire "Placing indexes on Filegroups" du BOL, notament le 2ème paragraphe.

Cordialement,
LionelP




"Timur" a écrit :

Bonjour,

A Fred :
Merci pour ces précisions même si le ton est toujours aussi ... direct.
J'avais bien compris que pour un index cluster les données sont la table
elle-même. Il y a néanmoins bien des pages d'index, non ? Bon, SQL 2k ne
permet pas de séparer ces pages d'index des feuilles du b-tree clustered,
c'est sa conception des choses. C'est géré de façon différente par d'autres
SGBD.

A Lionel :
J'ai appris qu'il pouvait être important de séparer les datas et les index
sur des disques différents. Si on a plusieurs datafiles, SQL va les remplir
chacun au fur et à mesure, ou bascule du premier vers le second quand
celui-ci est plein ? Je ne comprend pas trop pourquoi il y aurait un
problème de contention au niveau d'un groupe d'index.


--
Cordialement

Omnia vanitas


"Lionelp" a écrit dans le message de
news:
> Bonjour,
>
> En plus de ce que dit Fred, il n'est pas conseillé de mettre les index
dans
> des file groups spécifiques car la contention va se reporter sur ce ou ces
> file groups. On conseille de créer plusieurs data files pour le file group
> par défaut de cette manière les IO seront répartis de manière égale sur
les
> différent data files.
> On crée un ou des file group(s) pour une ou plusieurs tables pour des
soucis
> d'administration ou de découpage logique lorsque l'on a besoin de pouvoir
> restorer un file group ou une table.
>
> Cordialement,
> LionelP
>
> "Fred BROUARD" a écrit :
>
> > bonjour
> >
> > Timur a écrit:
> > > Merci Patrice...
> > >
> > > Comme quoi on ne lit jamais assez la doc... mea culpa !
> > >
> > > En tout cas, ca fait un peu peur (et ça peut réserver des surprises
> > > désagréables !) de voir que les datas sont déplacées sans autre forme
de
> > > procès !
> >
> > Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de type
CLUSTER !!!
> > Un index cluster contient TOUTE la table.
> > Un index cluster est constitué par les lignes de la table physiquement
ordonnés
> > dans le sens de la clef.
> > Déplacer un index cluster revient à déplacer la table.
> >
> > A +
> >
> > >
> > > merci
> > >
> >
> > --
> > Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> > Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> > Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> > ********************* http://www.datasapiens.com ***********************
> >
> >





Avatar
lionelp
ce que je n'ai pas exprimé clairement c'est:
si 2 filegroups alors leur remplissage se fait de manière totalement
indépendante.
le remplissage est parallélisé sur les datafiles d'un même filegroup.

Cordialement,
LionelP

"" a écrit :

Bonjour,

Si j'ai compris la remarque sur séparation data et index alors elle est
incorrecte.
Si j'ai plusieurs data files dans mon file group alors SQL Server va
paralléliser les IOs et les data files vont se remplir de manière égale ou à
peu près.
Si j'ai 1 filegroup pour les data et 1 pour les index je vais concentrer la
contention sur le filegroup des index car les data sont généralement accédées
à l'aide des index. Ou bien je fais un table scan et je n'utilise que le
filegroup des data au lieu des 2.
A lire "Placing indexes on Filegroups" du BOL, notament le 2ème paragraphe.

Cordialement,
LionelP




"Timur" a écrit :

> Bonjour,
>
> A Fred :
> Merci pour ces précisions même si le ton est toujours aussi ... direct.
> J'avais bien compris que pour un index cluster les données sont la table
> elle-même. Il y a néanmoins bien des pages d'index, non ? Bon, SQL 2k ne
> permet pas de séparer ces pages d'index des feuilles du b-tree clustered,
> c'est sa conception des choses. C'est géré de façon différente par d'autres
> SGBD.
>
> A Lionel :
> J'ai appris qu'il pouvait être important de séparer les datas et les index
> sur des disques différents. Si on a plusieurs datafiles, SQL va les remplir
> chacun au fur et à mesure, ou bascule du premier vers le second quand
> celui-ci est plein ? Je ne comprend pas trop pourquoi il y aurait un
> problème de contention au niveau d'un groupe d'index.
>
>
> --
> Cordialement
>
> Omnia vanitas
>
>
> "Lionelp" a écrit dans le message de
> news:
> > Bonjour,
> >
> > En plus de ce que dit Fred, il n'est pas conseillé de mettre les index
> dans
> > des file groups spécifiques car la contention va se reporter sur ce ou ces
> > file groups. On conseille de créer plusieurs data files pour le file group
> > par défaut de cette manière les IO seront répartis de manière égale sur
> les
> > différent data files.
> > On crée un ou des file group(s) pour une ou plusieurs tables pour des
> soucis
> > d'administration ou de découpage logique lorsque l'on a besoin de pouvoir
> > restorer un file group ou une table.
> >
> > Cordialement,
> > LionelP
> >
> > "Fred BROUARD" a écrit :
> >
> > > bonjour
> > >
> > > Timur a écrit:
> > > > Merci Patrice...
> > > >
> > > > Comme quoi on ne lit jamais assez la doc... mea culpa !
> > > >
> > > > En tout cas, ca fait un peu peur (et ça peut réserver des surprises
> > > > désagréables !) de voir que les datas sont déplacées sans autre forme
> de
> > > > procès !
> > >
> > > Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de type
> CLUSTER !!!
> > > Un index cluster contient TOUTE la table.
> > > Un index cluster est constitué par les lignes de la table physiquement
> ordonnés
> > > dans le sens de la clef.
> > > Déplacer un index cluster revient à déplacer la table.
> > >
> > > A +
> > >
> > > >
> > > > merci
> > > >
> > >
> > > --
> > > Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> > > Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> > > Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> > > ********************* http://www.datasapiens.com ***********************
> > >
> > >
>
>
>


Avatar
Timur
Merci pour le lien sur le BOL, l'article est très clair (je me demande
comment j'ai pu ne pas le trouver !)

Effectivement, au vue de ces infos, mon approche est mauvaise.

Merci d'avoir pris le temps de m'éclairer.

Cordialement

-----------------------------------------
Omnia vanitas


""
a écrit dans le
message de news:
ce que je n'ai pas exprimé clairement c'est:
si 2 filegroups alors leur remplissage se fait de manière totalement
indépendante.
le remplissage est parallélisé sur les datafiles d'un même filegroup.

Cordialement,
LionelP

"" a écrit :

> Bonjour,
>
> Si j'ai compris la remarque sur séparation data et index alors elle est
> incorrecte.
> Si j'ai plusieurs data files dans mon file group alors SQL Server va
> paralléliser les IOs et les data files vont se remplir de manière égale


ou à
> peu près.
> Si j'ai 1 filegroup pour les data et 1 pour les index je vais concentrer


la
> contention sur le filegroup des index car les data sont généralement


accédées
> à l'aide des index. Ou bien je fais un table scan et je n'utilise que le
> filegroup des data au lieu des 2.
> A lire "Placing indexes on Filegroups" du BOL, notament le 2ème


paragraphe.
>
> Cordialement,
> LionelP
>
>
>
>
> "Timur" a écrit :
>
> > Bonjour,
> >
> > A Fred :
> > Merci pour ces précisions même si le ton est toujours aussi ...


direct.
> > J'avais bien compris que pour un index cluster les données sont la


table
> > elle-même. Il y a néanmoins bien des pages d'index, non ? Bon, SQL 2k


ne
> > permet pas de séparer ces pages d'index des feuilles du b-tree


clustered,
> > c'est sa conception des choses. C'est géré de façon différente par


d'autres
> > SGBD.
> >
> > A Lionel :
> > J'ai appris qu'il pouvait être important de séparer les datas et les


index
> > sur des disques différents. Si on a plusieurs datafiles, SQL va les


remplir
> > chacun au fur et à mesure, ou bascule du premier vers le second quand
> > celui-ci est plein ? Je ne comprend pas trop pourquoi il y aurait un
> > problème de contention au niveau d'un groupe d'index.
> >
> >
> > --
> > Cordialement
> >
> > Omnia vanitas
> >
> >
> > "Lionelp" a écrit dans le message


de
> > news:
> > > Bonjour,
> > >
> > > En plus de ce que dit Fred, il n'est pas conseillé de mettre les


index
> > dans
> > > des file groups spécifiques car la contention va se reporter sur ce


ou ces
> > > file groups. On conseille de créer plusieurs data files pour le file


group
> > > par défaut de cette manière les IO seront répartis de manière égale


sur
> > les
> > > différent data files.
> > > On crée un ou des file group(s) pour une ou plusieurs tables pour


des
> > soucis
> > > d'administration ou de découpage logique lorsque l'on a besoin de


pouvoir
> > > restorer un file group ou une table.
> > >
> > > Cordialement,
> > > LionelP
> > >
> > > "Fred BROUARD" a écrit :
> > >
> > > > bonjour
> > > >
> > > > Timur a écrit:
> > > > > Merci Patrice...
> > > > >
> > > > > Comme quoi on ne lit jamais assez la doc... mea culpa !
> > > > >
> > > > > En tout cas, ca fait un peu peur (et ça peut réserver des


surprises
> > > > > désagréables !) de voir que les datas sont déplacées sans autre


forme
> > de
> > > > > procès !
> > > >
> > > > Pourquoi ? Parce que vous n'avez pas compris ce qu'est un index de


type
> > CLUSTER !!!
> > > > Un index cluster contient TOUTE la table.
> > > > Un index cluster est constitué par les lignes de la table


physiquement
> > ordonnés
> > > > dans le sens de la clef.
> > > > Déplacer un index cluster revient à déplacer la table.
> > > >
> > > > A +
> > > >
> > > > >
> > > > > merci
> > > > >
> > > >
> > > > --
> > > > Frédéric BROUARD, MVP SQL Server, expert bases de données et


langage SQL
> > > > Le site sur le langage SQL et les SGBDR :


http://sqlpro.developpez.com
> > > > Audit, conseil, expertise, formation, modélisation, tuning,


optimisation
> > > > ********************* http://www.datasapiens.com


***********************
> > > >
> > > >
> >
> >
> >