2009-08-10 6 views
32

auflisten Kennt jemand eine Abfrage für das Auflisten aller Fremdschlüssel in einer Datenbank mit "WITH NOCHECK" Beschreibung, die auf es angewandt wird? (Durch das Entfernen werden Leistung und Stabilität verbessert).Wie alle Fremdschlüssel mit "WITH NOCHECK" in SQL Server

+1

Welche Version von SQL Server? –

+0

SQL Server 2005 – digiguru

+0

Jungs, ich brauche das gleiche, aber sql 2000 kompatibel! –

Antwort

30

Im Folgenden wird den Namen des Fremdschlüssels in den aktuellen Rück Datenbank, die deaktiviert, dh mit NOCHECK

Für SQL Server 2005/2008 sind:

select * from sys.foreign_keys where is_disabled=1 




Es gab einige Diskussionen in der Antwort über den Unterschied zwischen behinderten & nicht vertrauenswürdig. Was ist unten erklärt der Unterschied Hier ist ein Code, um den Unterschied zwischen is_disabled & Isnotrusted zu verdeutlichen.

-- 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 bedeutet die Einschränkung deaktiviert ist

isnottrusted bedeutet, dass SQL Server nicht vertraut, dass die Säule gegen die Fremdschlüsseltabelle geprüft wurde.

Daher kann nicht davon ausgegangen werden, dass die erneute Aktivierung der Fremdschlüsseleinschränkung optimiert wird. Um sicherzustellen, dass der Optimierer der Spalte vertraut, wird empfohlen, die Fremdschlüsseleinschränkung & mit der Option WITH CHECK neu zu erstellen (4.)

+1

Sorry, ich habe diese Antwort gerade erst gelesen. Es ist wirklich großartig! – digiguru

+10

Sie können die Einschränkung erneut aktivieren und gleichzeitig mit dem folgenden Code prüfen lassen: 'ALTER TABLE t1 MIT CHECK CHECK CONSTRAINT fk_1' Dies ist etwas einfacher als das Löschen und erneute Erstellen der Constraint. – Aaron

5

NOCHECK sollte immer nur vorübergehend auf FKs angewendet werden, oder sie werden für den Optimierer nutzlos, wie Ihr verknüpfter Artikel darauf hinweist. Von BOL:

Der Abfrageoptimierer berücksichtigt nicht Einschränkungen, die mit NOCHECK definiert sind. Solche Einschränkungen werden ignoriert , bis sie wieder aktiviert werden, indem ALTER TABLE Tabelle CHECK CONSTRAINT ALL verwendet.

Dies identifizieren alle Fremdschlüssel: (auf das Bit mit NOCHECK arbeiten ...)

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.

Als beiseite, sowohl in SQL Server 2000 und 2005 können Sie überprüfen, ob alle Daten eine Einschränkung verletzt mit:

DBCC CHECKCONSTRAINTS (table_name) 
+0

DBCC CHECKCONSTRAINTS ist nützlich, aber das beantwortet wirklich die Frage nicht. – digiguru

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

Die Spalte is_not_trusted bedeutet, dass der SQL-Server * die Werte nicht überprüft hat, um die FK-Integrität sicherzustellen. Wenn die Beschränkung jemals einen NOCHECK angewendet hat! Dies ist ziemlich clever und genau das, was der Optimierer verwenden wird, um herauszufinden, ob er der Integrität der Spalte vertrauen kann. Also, was Sie tun müssen, ist nicht nur die Einschränkung wieder zu aktivieren, aber überprüfen Sie die Spalte –

+0

, aber es war nicht "deaktiviert". Wie würden Sie vorschlagen, es "wieder zu aktivieren"? – digiguru

+0

+1: digiguru, http://msdn.microsoft.com/en-us/library/ms189807.aspx Sie können den Schlüssel wie folgt überprüfen: 'ALTER TABLE [Schema]. [Tabelle] CHECK CONSTRAINT [FK_myConstraint] ' – Brad

2

Der folgende Code ruft alle Fremdschlüssel ab, die mit WITH NOCHECK gekennzeichnet sind und dann verwendet werden eine ALTER-Anweisung, sie zu reparieren:

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

Das folgende Skript wird die ALTER-Anweisungen generiert, die sowohl vorhandene Daten überprüfen und neue Verletzungen für Fremdschlüssel verhindern, die derzeit nicht vertrauenswürdig ist (‚mit nocheck‘).

Führen Sie sie in SQL Server Management Studio aus, um die Skripts zu generieren, und kopieren Sie sie anschließend in ein Abfragefenster, um sie auszuführen.

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

Ich weiß, das ist eine alte Frage mit einigen alten Antworten, die einige gute Informationen haben. Ich wollte jedoch nur ein Skript teilen, die ich verwendet habe für uns in ganz wenige verschiedenen Datenbanken diesen Problembereich zu adressieren:

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

Dies wird eine Sammlung von ALTER-Anweisungen erzeugt dieses „NOCHECK“ Problem zu beheben mit Fremdschlüsseln und Einschränkungen. Dies basiert auf einigen Abfragen, die von Brent Ozar zur Verfügung gestellt werden, aber von mir für meine Zwecke und Benutzerfreundlichkeit optimiert. Dies könnte leicht mit einer UNION optimiert werden, um es zu einer einzigen Abfrage zu machen.

FYI, ich habe dies ausschließlich in Azure SQL-Datenbank-Umgebungen verwendet. Ich bin mir nicht sicher, ob es Einschränkungen für ältere Versionen von SQL Server gibt, aber es funktioniert großartig in Azure.

Verwandte Themen