Si mes souvenirs sont exacts, le DB snapshot n'est possible qu'en
version Entreprise : oui / non
J'ai un doute sur les tables partitionnées (elles existent en quelles
versions ?)
Si l'on part de rien, créer une table partitionnée ne représente pas de
grande difficulé, il n' y a qu'à suivre l'exemple en BOL.
Par contre, pour l'alimentation de cette table, les
inserts/updates/delete se font directement sur la table source ou sur
les tables partitionnées, de même pour les select ? ou est-ce simplement
que dans un sens ?
Si une table est existante et que l'on souhaite la partitionner, dans ce
cas, que se passe-t-il ? Les données sont-elles conservées ? et comment
les interrogent-on ? On ne risque pas d'avoir les mêmes noms de tables ?
Merci d'avance pour votre aide.
Cordialement,
Forum
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
Christian Robert
Bonjour,
Oui uniquement en édition Enterprise.
Pour le partionnement celà dépend du type utilisé... Si c'est le système de partitionnement natif de SQL Server 2005, c'est uniquement en édition Enterprise.
Il est aussi possible de partitionner les données à l'aide de table regroupées par des vues et celà dans toutes les éditions. L'édition Enterprise offre à ce niveau la possiblité d'utiliser des tables situées sur des serveurs distants. (à partir de SQL Server 2000)
Pour les réponses suivantes celà dépend du type de partitionnement utilisé.
Pour le système de partitionnement natif de SQL Server 2005 ne voit qu'une seule et unique table qui comporte des partitions. Ces partitions sont transparente vu q'un utilisateur lambda pour lequel il y a toujours qu'une table. C'est le moteur qui gère entièrement ce système (INSERT / DELETE / UPDATE / SELECT)
Pour ce qui du partitionnement d'une table existante il faut soit créer un index clustered suivant le schéma de partitionnement que l'on souhaite, soit le réaliser sur une table vide ou partiellement vide et faire un switch.
Pour l'autre le partionnement (2000 / 2005) se faisant dans des tables distinctes, c'est à vous de gérer le tout. On peut faire les SELECT sur la vue, et les mise à jour sur la vue (mais j'ai eu des personnes me remontant des problèmes de lenteur de cette manière) ou directement dans les tables de base.
J'espère vous avoir éclairé sur le sujet.
-- Cordialement, Christian Robert - Winwise http://blogs.developpeur.org/christian/ MVP SQL Server - MCT - MCDBA - MCITP SQL
"Forums Microsoft" a écrit :
Bonjour à toutes et à tous,
Si mes souvenirs sont exacts, le DB snapshot n'est possible qu'en version Entreprise : oui / non
J'ai un doute sur les tables partitionnées (elles existent en quelles versions ?)
Si l'on part de rien, créer une table partitionnée ne représente pas de grande difficulé, il n' y a qu'à suivre l'exemple en BOL.
Par contre, pour l'alimentation de cette table, les inserts/updates/delete se font directement sur la table source ou sur les tables partitionnées, de même pour les select ? ou est-ce simplement que dans un sens ?
Si une table est existante et que l'on souhaite la partitionner, dans ce cas, que se passe-t-il ? Les données sont-elles conservées ? et comment les interrogent-on ? On ne risque pas d'avoir les mêmes noms de tables ?
Merci d'avance pour votre aide. Cordialement, Forum
Bonjour,
Oui uniquement en édition Enterprise.
Pour le partionnement celà dépend du type utilisé... Si c'est le système de
partitionnement natif de SQL Server 2005, c'est uniquement en édition
Enterprise.
Il est aussi possible de partitionner les données à l'aide de table
regroupées par des vues et celà dans toutes les éditions. L'édition
Enterprise offre à ce niveau la possiblité d'utiliser des tables situées sur
des serveurs distants. (à partir de SQL Server 2000)
Pour les réponses suivantes celà dépend du type de partitionnement utilisé.
Pour le système de partitionnement natif de SQL Server 2005 ne voit qu'une
seule et unique table qui comporte des partitions. Ces partitions sont
transparente vu q'un utilisateur lambda pour lequel il y a toujours qu'une
table. C'est le moteur qui gère entièrement ce système (INSERT / DELETE /
UPDATE / SELECT)
Pour ce qui du partitionnement d'une table existante il faut soit créer un
index clustered suivant le schéma de partitionnement que l'on souhaite, soit
le réaliser sur une table vide ou partiellement vide et faire un switch.
Pour l'autre le partionnement (2000 / 2005) se faisant dans des tables
distinctes, c'est à vous de gérer le tout. On peut faire les SELECT sur la
vue, et les mise à jour sur la vue (mais j'ai eu des personnes me remontant
des problèmes de lenteur de cette manière) ou directement dans les tables de
base.
J'espère vous avoir éclairé sur le sujet.
--
Cordialement,
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MVP SQL Server - MCT - MCDBA - MCITP SQL
"Forums Microsoft" a écrit :
Bonjour à toutes et à tous,
Si mes souvenirs sont exacts, le DB snapshot n'est possible qu'en
version Entreprise : oui / non
J'ai un doute sur les tables partitionnées (elles existent en quelles
versions ?)
Si l'on part de rien, créer une table partitionnée ne représente pas de
grande difficulé, il n' y a qu'à suivre l'exemple en BOL.
Par contre, pour l'alimentation de cette table, les
inserts/updates/delete se font directement sur la table source ou sur
les tables partitionnées, de même pour les select ? ou est-ce simplement
que dans un sens ?
Si une table est existante et que l'on souhaite la partitionner, dans ce
cas, que se passe-t-il ? Les données sont-elles conservées ? et comment
les interrogent-on ? On ne risque pas d'avoir les mêmes noms de tables ?
Merci d'avance pour votre aide.
Cordialement,
Forum
Pour le partionnement celà dépend du type utilisé... Si c'est le système de partitionnement natif de SQL Server 2005, c'est uniquement en édition Enterprise.
Il est aussi possible de partitionner les données à l'aide de table regroupées par des vues et celà dans toutes les éditions. L'édition Enterprise offre à ce niveau la possiblité d'utiliser des tables situées sur des serveurs distants. (à partir de SQL Server 2000)
Pour les réponses suivantes celà dépend du type de partitionnement utilisé.
Pour le système de partitionnement natif de SQL Server 2005 ne voit qu'une seule et unique table qui comporte des partitions. Ces partitions sont transparente vu q'un utilisateur lambda pour lequel il y a toujours qu'une table. C'est le moteur qui gère entièrement ce système (INSERT / DELETE / UPDATE / SELECT)
Pour ce qui du partitionnement d'une table existante il faut soit créer un index clustered suivant le schéma de partitionnement que l'on souhaite, soit le réaliser sur une table vide ou partiellement vide et faire un switch.
Pour l'autre le partionnement (2000 / 2005) se faisant dans des tables distinctes, c'est à vous de gérer le tout. On peut faire les SELECT sur la vue, et les mise à jour sur la vue (mais j'ai eu des personnes me remontant des problèmes de lenteur de cette manière) ou directement dans les tables de base.
J'espère vous avoir éclairé sur le sujet.
-- Cordialement, Christian Robert - Winwise http://blogs.developpeur.org/christian/ MVP SQL Server - MCT - MCDBA - MCITP SQL
"Forums Microsoft" a écrit :
Bonjour à toutes et à tous,
Si mes souvenirs sont exacts, le DB snapshot n'est possible qu'en version Entreprise : oui / non
J'ai un doute sur les tables partitionnées (elles existent en quelles versions ?)
Si l'on part de rien, créer une table partitionnée ne représente pas de grande difficulé, il n' y a qu'à suivre l'exemple en BOL.
Par contre, pour l'alimentation de cette table, les inserts/updates/delete se font directement sur la table source ou sur les tables partitionnées, de même pour les select ? ou est-ce simplement que dans un sens ?
Si une table est existante et que l'on souhaite la partitionner, dans ce cas, que se passe-t-il ? Les données sont-elles conservées ? et comment les interrogent-on ? On ne risque pas d'avoir les mêmes noms de tables ?
Merci d'avance pour votre aide. Cordialement, Forum
