Jak wyświetlić listę wszystkich kluczy obcych za pomocą "Z NOCHECKIEM" w SQL Server

Question

Czy ktoś zna zapytanie o wystawienie na sprzedaż wszystkich kluczy obcych w bazie danych z zastosowanym opisem "Z NOCHECKIEM"? (ich usunięcie zwiększy wydajność i stabilność).

Answer 1

Poniższa zwróci nazwę z kluczy obcych w prądzie bazy danych, które są wyłączone tj nocheck

Dla SQL Server 2005/2008:

select * from sys.foreign_keys where is_disabled=1 

---

Było trochę dyskusji w odpowiedzi na temat różnicy między niepełnosprawnych & nie zaufanego. Poniżej znajduje się wyjaśnienie różnicy. Oto kod wyjaśniający różnicę między 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 oznacza ograniczenie jest wyłączone

isnottrusted oznacza, że ​​SQL Server nie ufa, że ​​kolumna została sprawdzona przed tabeli klucza obcego.

Dlatego nie można założyć, że ponowne włączenie ograniczenia klucza obcego zostanie zoptymalizowane. Aby zapewnić optymalizatorowi zaufanie do kolumny, najlepiej jest usunąć ograniczenie klucza obcego & ponownie utworzyć je za pomocą opcji WITH CHECK (4.)

Answer 2

Z NOCHECK należy tylko stosować tymczasowo do FK lub stają się bezużyteczne dla optymalizatora, jak wskazuje na to link. Od BOL:

optymalizator kwerendy nie uważa ograniczenia, które są definiowane nocheck. Takie ograniczenia są ignorowane , dopóki nie zostaną ponownie włączone za pomocą tabeli strojenia ALTER TABLE CHECK CONSTRAINT ALL.

To będzie zidentyfikowanie wszystkich kluczy obcych: (działa na nieco z 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.

Tak na marginesie, zarówno w SQL Server 2000 i 2005, można sprawdzić, czy jakiekolwiek dane narusza ograniczenie używając:

DBCC CHECKCONSTRAINTS (table_name) 

Answer 3

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

Answer 4

Poniższy kod pobiera wszystkie klucze obce oznaczone jako "Z NOCHECK", a następnie wykorzystuje instrukcja ALTER naprawić je:

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

Answer 5

Poniższy skrypt wygeneruje ALTER która będzie zarówno sprawdzić istniejące dane i uniemożliwić żadnych nowych naruszeń dla kluczy obcych, które nie są obecnie zaufanych („z nocheck”).

Wykonaj go w SQL Server Management Studio, aby wygenerować skrypty, a następnie skopiuj je do okna zapytania, aby je wykonać.

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 

Answer 6

Wiem, że to stare pytanie z kilkoma starymi odpowiedziami, które mają dobre informacje. Jednakże, po prostu chciałem podzielić się skrypt, który używam do rozwiązania tego obszaru problemowego w dość kilka różnych baz danych do nas:

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

To będzie generować zbiór ALTER rozwiązać ten „nocheck” problem z kluczami obcymi i ograniczeniami. Jest to oparte na pewnych pytaniach dostarczonych przez Brent Ozar, ale poprawionych przeze mnie dla moich celów i łatwości użycia. Można to łatwo poprawić za pomocą UNION, aby było to pojedyncze zapytanie.

FYI, użyłem tego wyłącznie w środowiskach baz danych SQL Azure. Nie jestem pewien, czy istnieją ograniczenia dotyczące starszych wersji SQL Server, ale działa świetnie na Azure.