Sql Server Clé Primaire De La Partition Problème

Je fais construire une table qui sera partitionné et contiennent un FILESTREAM colonne. La question que je rencontre est qu'il semble que je dois avoir une clé primaire composite (FILE_ID et FILE_UPLOADED_DATE) parce que FILE_UPLOADED_DATE est une partie de mon schéma de partition. Est-ce exact? Je préfère ne pas avoir ce être une clé composite et il suffit juste d'avoir FILE_ID étant la clé primaire.....cela pourrait-il être juste une erreur de l'utilisateur?

Toutes les suggestions seraient appréciées.

Version: SQL Server 2008 R2

Schémas de Partition et de la Fonction:

CREATE PARTITION FUNCTION DocPartFunction (datetime)
AS RANGE RIGHT FOR VALUES ('20101220')
GO
CREATE PARTITION SCHEME DocPartScheme AS
PARTITION DocPartFunction TO (DATA_FG_20091231, DATA_FG_20101231);
GO
CREATE PARTITION SCHEME DocFSPartScheme AS
PARTITION DocPartFunction TO (FS_FG_20091231,FS_FG_20101231);
GO

Instruction De Création:

CREATE TABLE [dbo].[FILE](
    [FILE_ID] [int] IDENTITY(1,1) NOT NULL,
    [DOCUMENT] [varbinary](max) FILESTREAM  NULL,
    [FILE_UPLOADED_DATE] [datetime] NOT NULL,
    [FILE_INT] [int] NOT NULL,
    [FILE_EXTENSION] [varchar](10) NULL,
    [DocGUID] [uniqueidentifier] ROWGUIDCOL  NOT NULL UNIQUE ON [PRIMARY],
CONSTRAINT [PK_File] PRIMARY KEY CLUSTERED
    (   [FILE_ID] ASC
    ) ON DocPartScheme ([FILE_UPLOADED_DATE])
)ON DocPartScheme ([FILE_UPLOADED_DATE])
FILESTREAM_ON DocFSPartScheme;

Erreur si je ne comprend pas FILE_UPLOADED_DATE:

Msg 1908, Level 16, State 1, Line 1
Column 'FILE_UPLOADED_DATE' is partitioning column of the index 'PK_File'. Partition columns for a unique index must be a subset of the index key.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.

Merci!

OriginalL'auteur scarpacci | 2011-10-04

9

Vous confondez la clé primaire et l'index cluster. Il n'y a aucune raison pour que les deux seront une seule et même chose. Vous pouvez avoir un index cluster sur FILE_UPLOADED_DATE et un autre, non-cluster, clé primaire sur FILE_ID. En fait, vous le faites déjà quelque chose de similaire pour le DocGUID colonne:
```
CREATE TABLE [dbo].[FILE](
    [FILE_ID] [int] IDENTITY(1,1) NOT NULL,
    [DOCUMENT] [varbinary](max) FILESTREAM  NULL,
    [FILE_UPLOADED_DATE] [datetime] NOT NULL,
    [FILE_INT] [int] NOT NULL,
    [FILE_EXTENSION] [varchar](10) NULL,
    [DocGUID] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
    constraint UniqueDocGUID UNIQUE NONCLUSTERED ([DocGUID]) 
        ON [PRIMARY])
    ON DocPartScheme ([FILE_UPLOADED_DATE])
    FILESTREAM_ON DocFSPartScheme;

CREATE CLUSTERED INDEX cdx_File 
   ON [FILE] (FILE_UPLOADED_DATE)
   ON DocPartScheme ([FILE_UPLOADED_DATE])
   FILESTREAM_ON DocFSPartScheme;

ALTER TABLE [dbo].[FILE]
    ADD CONSTRAINT PK_File PRIMARY KEY NONCLUSTERED (FILE_ID)
    ON [PRIMARY];
```
Cependant, une telle conception va conduire à la non-alignés indices qui peuvent provoquer de très graves problèmes de performance, et aussi de bloquer tous les rapide opérations de commutation de partition. Voir Directives spéciales pour les Index Partitionnés:

Chaque table de tri nécessite une quantité minimale de mémoire à construire. Lorsque vous
créez un index partitionné qui est aligné avec sa table de base,
les tables de tri sont construit une à la fois, en utilisant moins de mémoire. Toutefois, lorsque
vous êtes à la construction d'un index partitionné non aligné, les tables de tri sont
construite à la même époque.

Comme un résultat, il doit y avoir suffisamment de mémoire pour gérer ces
tri simultanés. Plus le nombre de partitions, plus de mémoire
nécessaire. La taille minimale pour chaque table de tri, pour chaque partition, est
40 pages, avec 8 kilo-octets par page. Par exemple, un non-alignés
index partitionné avec 100 partitions a besoin de suffisamment de mémoire pour
trier en série de 4 000 (40 * 100) pages en même temps. Si cette mémoire
est disponible, l'opération de création de réussir, mais les performances peuvent
souffrir. Si cette mémoire n'est pas disponible, l'opération de création d'échouer

Votre conception a déjà un non-aligné de l'indice pour DocGUID, de sorte que les problèmes de performances sont probablement déjà présent. Si vous devez garder votre index alignés, alors vous devez admettre que l'un des effets secondaires de choisir un schéma de partition: vous ne pouvez plus avoir une clé primaire logique, ni les contraintes unique application de la loi, à moins que la clé comprend le partitionnement de la clé.

Et enfin, on doit se demander: pourquoi utiliser une table partitionnée? Ils sont toujours plus lent qu'un non-partitionné alternative. Sauf si vous avez besoin rapide d'opérations de commutation de partition pour ETL (que vous êtes déjà la barque en raison de la non-alignés index sur DocGUID), il n'y a fondamentalement aucune incitation à l'utilisation d'une table partitionnée. (Préemptif commentaire: index cluster sur la FILE_UPLOADED_DATE à la garantie d'une meilleure alternative que de "partition élimination").

Remus, je vous remercie beaucoup pour les informations. J'ai besoin de la partition afin que je puisse prendre le groupe de fichiers filestream à un autre emplacement.....mais seulement les plus récents, parce que nous avons l'espace limitiations....c'est une longue histoire.
la solution ci-dessus que vous avez fourni ne fonctionne pas? Une partie de c'est à cause du mot réservé "FILE_ID", mais après la correction qu'il l'est encore de jeter des erreurs lorsque j'essaye de créer la table avec la structure ci-dessus.
J'ai corrigé mon script (testé cette fois-ci). À l'aide de partitionnement pour un groupe de fichiers de gestion est une raison valable pour déployer le partitionnement. Malheureusement, le FILESTREAM exigence d'une contrainte Unique sur la ROWGUIDCOL est une garantie de non-alignées index et cela peut provoquer des problèmes dans l'avenir (par exemple. si vous avez besoin d'utiliser rapide changement de partition à supprimer des documents qui ont étendu le max mandat politique de conservation durée de vie).
Merci Remus! Apprécie vraiment l'aider.

OriginalL'auteur Remus Rusanu
4

La colonne de partitionnement doit toujours être présent dans une table partitionnée de l'index cluster. Toute activité de travail autour de vous est venu a à ce facteur.

OriginalL'auteur Philip Kelley
0

Je sais, c'est une vieille question, mais peut-être que google mène quelqu'un d'autre à cette question:

Une solution possible serait de ne pas la partition par la date-colonne, mais par la File_ID. Chaque jour /semaine /mois (ou quelle que soit la période de temps que vous utilisez), vous devez exécuter une Tâche de l'Agent, à minuit, qui prend la Max(File_ID) où file_uploadet_date < GetDate(), ajoute le prochain groupe de fichiers pour la partition système et un split sur le MaxID + 1.

Bien sûr, vous aurez toujours le problème avec les non alignés de l'index sur la carte d'identité du document, à l'exception de vous eighter ajouter le file_id à cet index unique (pourrait entraîner la non unique clés docids) et /ou de vérifier son caractère unique dans une insertion /mise à jour le déclencheur.

OriginalL'auteur Thomas Franz

Vous devez vous connecter pour publier un commentaire.