2009-08-10 7 views

Répondre

30

Le tableau suivant retourne le nom des clés étrangères dans le courant base de données qui sont par exemple handicapés avec NOCHECK

Pour SQL Server 2005/2008:

select * from sys.foreign_keys where is_disabled=1 




On a discuté dans la réponse au sujet de la différence entre & désactivé ne fait confiance. Ce qui suit explique la différence Voici un code pour clarifier la différence entre is_disabled & isnotrusted.

-- drop table t1 
-- drop table t2 
create table t1(i int not null, fk int not null) 
create table t2(i int not null) 
-- create primary key on t2 
alter table t2 
add constraint pk_1 primary key (i) 
-- create foriegn key on t1 
alter table t1 
add constraint fk_1 foreign key (fk) 
    references t2 (i) 
--insert some records 
insert t2 values(100) 
insert t2 values(200) 
insert t2 values(300) 
insert t2 values(400) 
insert t2 values(500) 
insert t1 values(1,100) 
insert t1 values(2,100) 
insert t1 values(3,500) 
insert t1 values(4,500) 
---------------------------- 
-- 1. enabled and trusted 
select name,is_disabled,is_not_trusted from sys.foreign_keys 
GO 

-- 2. disable the constraint 
alter table t1 NOCHECK CONSTRAINT fk_1 
select name,is_disabled,is_not_trusted from sys.foreign_keys 
GO 

-- 3. re-enable constraint, data isnt checked, so not trusted. 
-- this means the optimizer will still have to check the column 
alter table t1 CHECK CONSTRAINT fk_1 
select name,is_disabled,is_not_trusted from sys.foreign_keys 
GO 

--4. drop the foreign key constraint & re-add 
-- it making sure its checked 
-- constraint is then enabled and trusted 
alter table t1 DROP CONSTRAINT fk_1 
alter table t1 WITH CHECK 
add constraint fk_1 foreign key (fk) 
    references t2 (i) 
select name,is_disabled,is_not_trusted from sys.foreign_keys 
GO 


--5. drop the foreign key constraint & add but dont check 
-- constraint is then enabled, but not trusted 
alter table t1 DROP CONSTRAINT fk_1 
alter table t1 WITH NOCHECK 
add constraint fk_1 foreign key (fk) 
    references t2 (i) 
select name,is_disabled,is_not_trusted from sys.foreign_keys 
GO 

is_disabled signifie que la contrainte est désactivée

isnottrusted signifie que SQL Server ne fait pas confiance que la colonne a été vérifiée sur la table clé étrangère.

Ainsi, il ne peut pas être supposé que la réactivation de la contrainte de clé étrangère sera optimisée. Pour que l'optimiseur approuve la colonne, il est préférable de supprimer la contrainte de clé étrangère & en la recréant avec l'option WITH CHECK (4.)

+1

Désolé, je viens juste de lire cette réponse. C'est vraiment génial! – digiguru

+10

Vous pouvez réactiver la contrainte et l'ont vérifié en même temps avec le code suivant: 'ALTER TABLE t1 AVEC CONTRAINTE CHECK CHECK fk_1' Ceci est un peu plus simple que de laisser tomber et recréer la contrainte. – Aaron

5

AVEC NOCHECK ne devrait être appliqué que temporairement sur les FK, ou devenir inutile pour l'optimiseur, comme l'indique votre article lié. De BOL:

L'optimiseur de requêtes ne considère pas contraintes définies avec NOCHECK. Ces contraintes sont ignorées jusqu'à ce qu'elles soient réactivées en utilisant table ALTER TABLE VERIFIER CONTRAINTE ALL.

Cela permettra d'identifier toutes vos clés étrangères: (travail sur le bit AVEC NOCHECK ...)

SELECT C.TABLE_CATALOG [PKTABLE_QUALIFIER], 
     C.TABLE_SCHEMA [PKTABLE_OWNER], 
     C.TABLE_NAME [PKTABLE_NAME], 
     KCU.COLUMN_NAME [PKCOLUMN_NAME], 
     C2.TABLE_CATALOG [FKTABLE_QUALIFIER], 
     C2.TABLE_SCHEMA [FKTABLE_OWNER], 
     C2.TABLE_NAME [FKTABLE_NAME], 
     KCU2.COLUMN_NAME [FKCOLUMN_NAME], 
     RC.UPDATE_RULE, 
     RC.DELETE_RULE, 
     C.CONSTRAINT_NAME [FK_NAME], 
     C2.CONSTRAINT_NAME [PK_NAME], 
     CAST(7 AS SMALLINT) [DEFERRABILITY] 
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS C 
     INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KCU 
     ON C.CONSTRAINT_SCHEMA = KCU.CONSTRAINT_SCHEMA 
      AND C.CONSTRAINT_NAME = KCU.CONSTRAINT_NAME 
     INNER JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS RC 
     ON C.CONSTRAINT_SCHEMA = RC.CONSTRAINT_SCHEMA 
      AND C.CONSTRAINT_NAME = RC.CONSTRAINT_NAME 
     INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS C2 
     ON RC.UNIQUE_CONSTRAINT_SCHEMA = C2.CONSTRAINT_SCHEMA 
      AND RC.UNIQUE_CONSTRAINT_NAME = C2.CONSTRAINT_NAME 
     INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KCU2 
     ON C2.CONSTRAINT_SCHEMA = KCU2.CONSTRAINT_SCHEMA 
      AND C2.CONSTRAINT_NAME = KCU2.CONSTRAINT_NAME 
      AND KCU.ORDINAL_POSITION = KCU2.ORDINAL_POSITION 
WHERE C.CONSTRAINT_TYPE = 'FOREIGN KEY' 

Ref.

En aparté, dans SQL Server 2000 et 2005, vous pouvez vérifier si les données viole une contrainte en utilisant:

DBCC CHECKCONSTRAINTS (table_name) 
+0

DBCC CHECKCONSTRAINTS est utile, mais cela ne répond vraiment pas à la question. – digiguru

9
SELECT * FROM sys.foreign_keys AS f Where Is_Not_Trusted = 1 
+1

La colonne is_not_trusted signifie que le serveur SQL n'a pas * vérifié * les valeurs pour garantir l'intégrité FK. c'est-à-dire si la contrainte a déjà eu une NOCHECK appliquée! C'est assez intelligent et en fait ce que l'optimiseur utilisera pour déterminer s'il peut faire confiance à l'intégrité de la colonne. Donc, ce que vous devez faire est non seulement de réactiver la contrainte, mais revérifiez la colonne –

+0

Mais ce n'était pas "désactivé". Comment suggéreriez-vous de le «réactiver»? – digiguru

+0

+1: digiguru, http://msdn.microsoft.com/en-us/library/ms189807.aspx Vous pouvez revérifier la clé comme suit: 'ALTER TABLE [schéma]. [Table] CHECK CONSTRAINT [FK_myConstraint] ' – Brad

2

Le code suivant récupère toutes les clés étrangères marquées "WITH NOCHECK", puis utilise une déclaration ALTER les réparer:

-- configure cursor on all FKs with "WITH NOCHECK" 
DECLARE UntrustedForeignKeysCursor CURSOR STATIC FOR 
    SELECT f.name, 
      t.name 
    FROM sys.foreign_keys AS f 
      LEFT JOIN sys.tables AS t 
       ON f.parent_object_id = t.object_id 
    Where Is_Not_Trusted = 1 
OPEN UntrustedForeignKeysCursor 

-- loop through the untrusted FKs 
DECLARE @FKName varchar(100) 
DECLARE @TableName varchar(100) 
FETCH NEXT FROM UntrustedForeignKeysCursor INTO @FKName, @TableName 
WHILE @@FETCH_STATUS = 0 
BEGIN 

    -- Rebuild the FK constraint WITH CHECK 
    EXEC ('ALTER TABLE ' + @TableName + ' WITH CHECK CHECK CONSTRAINT ' + @FKName) 

    -- get next user 
    FETCH NEXT FROM UntrustedForeignKeysCursor INTO @FKName, @TableName 

END 

-- cleanup 
CLOSE UntrustedForeignKeysCursor 
7

Le script suivant va générer les déclarations alter qui à la fois vérifier les données existantes et de prévenir toute nouvelle violation des clés étrangères qui ne sont pas actuellement confiance (« avec nocheck »).

Exécutez-le dans SQL Server Management Studio pour générer les scripts, puis copiez-les dans une fenêtre de requête pour les exécuter.

select 
    'alter table ' + quotename(s.name) + '.' + quotename(t.name) + ' with check check constraint ' + fk.name +';' 
from 
    sys.foreign_keys fk 
inner join 
    sys.tables t 
on 
    fk.parent_object_id = t.object_id 
inner join 
    sys.schemas s 
on 
    t.schema_id = s.schema_id 
where 
    fk.is_not_trusted = 1 
0

Je sais que c'est une vieille question avec quelques vieilles réponses qui ont de bonnes informations. Cependant, je voulais juste partager un script que je l'ai utilisé pour traiter cette problématique dans un certain nombre de bases de données différentes pour nous:

-- Foreign Keys 
SELECT 'ALTER TABLE ' + o.name + ' WITH CHECK CHECK CONSTRAINT ' + i.name + ';' AS AlterStatement 
from sys.foreign_keys i 
INNER JOIN sys.objects o ON i.parent_object_id = o.object_id 
INNER JOIN sys.schemas s ON o.schema_id = s.schema_id 
WHERE i.is_not_trusted = 1 AND i.is_not_for_replication = 0; 
GO 

-- Constraints 
SELECT 'ALTER TABLE ' + o.name + ' WITH CHECK CHECK CONSTRAINT ' + i.name + ';' AS AlterStatement 
from sys.check_constraints i 
INNER JOIN sys.objects o ON i.parent_object_id = o.object_id 
INNER JOIN sys.schemas s ON o.schema_id = s.schema_id 
WHERE i.is_not_trusted = 1 AND i.is_not_for_replication = 0 AND i.is_disabled = 0; 
GO 

Cela va générer une collection de déclarations ALTER pour résoudre ce problème « NOCHECK » avec des clés et des contraintes étrangères. Ceci est basé sur certaines requêtes fournies par Brent Ozar mais modifié par mes fins et la facilité d'utilisation. Cela pourrait facilement être modifié avec un UNION pour en faire une seule requête.

FYI, je l'ai utilisé exclusivement dans les environnements Azure SQL Database. Je ne suis pas sûr s'il existe des limitations sur les anciennes versions de SQL Server, mais cela fonctionne très bien dans Azure.