2009-08-10 9 views

Respuesta

30

El siguiente devolverá el nombre de las claves externas en el actual es decir, la base de datos que son discapacitadas con NOCHECK

Para SQL Server 2005/2008:

select * from sys.foreign_keys where is_disabled=1 




hubo alguna discusión en la respuesta sobre la diferencia entre personas con discapacidad & no es de confianza. Lo que está debajo explica la diferencia Aquí hay un código para aclarar la diferencia entre is_disabled & isnotredit.

-- 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 que la restricción está desactivado

isnottrusted significa que SQL Server no confía en que la columna ha sido comprobado en contra de la tabla de clave externa.

Por lo tanto, no se puede suponer que se optimizará la habilitación de la restricción de la clave externa. Para asegurar los fideicomisos optimizador de la columna, lo mejor es quitar la restricción de clave externa & volver a crearlo con la opción WITH CHECK (4.)

+1

Lo siento, acabo de leer esta respuesta. ¡Es realmente grandioso! – digiguru

+10

Puede volver a habilitar la restricción y se debe verificar al mismo tiempo con el siguiente código: 'ALTER TABLE t1 WITH CHECK restricción CHECK fk_1' Esto es un poco más simple que caer y volver a crear la restricción. – Aaron

5

WITH NOCHECK solo deben aplicarse temporalmente a FK, o se vuelven inútiles para el optimizador como lo señala su artículo vinculado. De BOL:

El optimizador de consultas no considera limitaciones que se definen con NOCHECK. Tales restricciones se ignoran hasta que se vuelven a habilitar utilizando tabla ALTER TABLE CHECK CONSTRAINT ALL.

Esto le permitirá identificar todas sus claves externas: (trabajando en el 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.

Como acotación al margen, tanto en SQL Server 2000 y 2005, se puede comprobar si los datos infringe una restricción usando:

DBCC CHECKCONSTRAINTS (table_name) 
+0

DBCC CHECKCONSTRAINTS es útil, pero esto realmente no responde la pregunta. – digiguru

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

La columna is_not_trusted significa que el servidor sql no * ha verificado * los valores para garantizar la integridad de FK. es decir, si la restricción ha tenido alguna vez un NOCHECK aplicado. esto es bastante inteligente y, de hecho, lo que el optimizador utilizará para determinar si puede confiar en la integridad de la columna. Entonces, lo que tiene que hacer no es simplemente volver a habilitar la restricción, sino volver a verificar la columna –

+0

, pero no fue "deshabilitada". ¿Cómo sugeriría realizar "volver a habilitarlo"? – digiguru

+0

+1: digiguru, http://msdn.microsoft.com/en-us/library/ms189807.aspx Puede volver a marcar la clave de esta manera: 'ALTER TABLE [esquema]. [Tabla] CHECK CONSTRAINT [FK_myConstraint] ' – Brad

2

El código siguiente recupera todas las claves externas que están marcados 'CON NOCHECK' y luego usos una instrucción ALTER solucionarlos arriba:

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

La siguiente secuencia de comandos generará las declaraciones alter que a la vez comprobar los datos existentes y prevenir cualquier nueva violaciónes de las claves externas que no están actualmente de confianza ('con nocheck').

Ejecútelo en SQL Server Management Studio para generar los scripts y cópielos en una ventana de consulta para ejecutarlos.

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

Sé que esta es una vieja pregunta con algunas respuestas antiguas que tienen buena información. Sin embargo, sólo quería compartir un guión que he estado utilizando para hacer frente a esta problemática en un buen número de bases de datos diferentes para nosotros:

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

Esto generará un conjunto de instrucciones ALTER para solucionar este problema "NOCHECK" con claves foráneas y restricciones. Esto se basa en algunas consultas proporcionadas por Brent Ozar pero modificadas por mí para mis propósitos y facilidad de uso. Esto podría modificarse fácilmente con un UNION para convertirlo en una consulta única.

Para su información, he utilizado esto exclusivamente en entornos de Azure SQL Database. No estoy seguro de si existen limitaciones en las versiones anteriores de SQL Server, pero funciona muy bien en Azure.

Cuestiones relacionadas