2009-08-10 6 views

risposta

30

Di seguito restituirà il nome delle chiavi esterne nella corrente database che sono cioè disabili con NOCHECK

Per SQL Server 2005/2008:

select * from sys.foreign_keys where is_disabled=1 




Si è discusso nella risposta circa la differenza tra disabile & non attendibile. Di seguito è spiegata la differenza Ecco un codice per chiarire la differenza tra is_disabled & non supportato.

-- 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 significa che il vincolo è disabilitato

isnottrusted significa che SQL Server non si fida che la colonna è stata verificata contro il tavolo chiave esterna.

Pertanto, non si può presumere che la riattivazione del vincolo di chiave esterna venga ottimizzata. Per assicurarsi che l'ottimizzatore consideri attendibile la colonna, è preferibile eliminare il vincolo di chiave esterna & ricrearlo con l'opzione WITH CHECK (4.)

+1

Mi spiace, ho appena letto questa risposta. È davvero fantastico! – digiguru

+10

È possibile riattivare il vincolo e farlo controllare allo stesso tempo con il seguente codice: 'ALTER TABLE t1 WITH CHECK CHECK CONSTRAINT fk_1' Questo è un po 'più semplice di cadere e ricreare il vincolo. – Aaron

5

CON NOCHECK deve essere applicato solo temporaneamente a FK, altrimenti diventano inutili per l'ottimizzatore come indicato nell'articolo collegato. Da BOL:

Query Optimizer non considera vincoli definiti CON NOCHECK. Tali vincoli vengono ignorati fino a quando non vengono riattivati ​​utilizzando tabella ALTER TABLE CHECK CONSTRAINT ALL.

Ciò consentirà di individuare tutte le chiavi esterne: (lavorare sul bit con 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.

Per inciso, sia in SQL Server 2000 e il 2005, è possibile controllare se i dati viola un vincolo utilizzando:

DBCC CHECKCONSTRAINTS (table_name) 
+0

DBCC CHECKCONSTRAINTS è utile, ma in realtà non risponde alla domanda. – digiguru

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

La colonna is_not_trusted indica che il server sql non ha * controllato * i valori per garantire l'integrità FK. Ad esempio, se il vincolo ha mai avuto un NOCHECK applicato! questo è abbastanza intelligente e in effetti verrà utilizzato dall'ottimizzatore per capire se può fidarsi dell'integrità sulla colonna. Quindi, ciò che devi fare è non solo riattivare il vincolo, ma ricontrollare la colonna –

+0

ma non è stato "disabilitato". Come suggeriresti di eseguire "riabilitarlo"? – digiguru

+0

+1: digiguru, http://msdn.microsoft.com/en-us/library/ms189807.aspx È possibile ricontrollare la chiave in questo modo: 'ALTER TABLE [schema]. [Table] CONTROLLA CONSTRAINT [FK_myConstraint] ' – Brad

2

Il seguente codice recupera tutte le chiavi esterne contrassegnate come "WITH NOCHECK" e quindi utilizza un'istruzione ALTER risolverli up:

-- 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

Lo script che segue genererà le dichiarazioni alter che sia controllare i dati esistenti e prevenire eventuali nuove violazioni per le chiavi esterne che non sono attualmente (trusted 'con nocheck').

Eseguilo in SQL Server Management Studio per generare gli script e copiarli in una finestra di query per eseguirli.

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

So che questa è una vecchia domanda con alcune vecchie risposte che hanno alcune buone informazioni. Tuttavia, ho voluto solo condividere uno script che ho utilizzato per affrontare questa problematica in un bel paio di database diversi per noi:

-- 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 

Questo genererà un insieme di istruzioni ALTER per risolvere questo problema "NOCHECK" con chiavi e vincoli esterni. Questo è basato su alcune query fornite da Brent Ozar ma da me ottimizzate per i miei scopi e facilità d'uso. Questo potrebbe facilmente essere ottimizzato con un UNION per renderlo una singola query.

FYI, l'ho usato esclusivamente negli ambienti Database SQL di Azure. Non sono sicuro se esistono limitazioni sulle versioni precedenti di SQL Server, ma funziona perfettamente in Azure.