¿Cómo ocultar / deshabilitar tablas sin soltarlas para verificar la redundancia?

12

Tengo que mantener y ampliar un antiguo sistema heredado que contiene métodos de servicio web y tablas de bases de datos que ya no se usan. Como no estoy completamente seguro de que las tablas sean realmente redundantes, me temo que las descarte.

¿Hay alguna otra forma de lograr el mismo efecto (las tablas ya no se pueden usar) sin soltarlas? Mi idea era transferirlos a un esquema diferente (por ejemplo, Deleted) de la actual por defecto, dbo.

IF NOT EXISTS (SELECT * FROM sys.schemas WHERE name = 'Deleted')
BEGIN
   EXEC('CREATE SCHEMA Deleted')
END

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

¿Hay alguna otra opción o hay algún inconveniente en el enfoque de esquema?

— Tim Schmelter
fuente

7

¿Hay alguna otra forma de lograr lo mismo (las tablas ya no se pueden usar) sin soltarlas?

Un cambio de esquema es una operación muy rápida, solo se requiere un cambio de metadatos. La idea original que obtuve fue del blog de Aaron Bertrand: Schema Switch-A-Roo .

Puedes seguir los pasos de mi respuesta aquí

Obviamente, hay otros métodos como sp_rename N'old table ', N'new table' o simplemente negar permisos a la tabla.

— Kin Shah
fuente

No estaba seguro de qué respuesta debería aceptar porque todos son útiles. No conocía el artículo de Aaron, así que he aceptado esto ya que contiene más información (incluso si solo está vinculado).

— Tim Schmelter

@TimSchmelter Me alegra que lo hayas encontrado útil. No tiene sentido repetir aquí lo que el artículo o mi respuesta (vinculado). Por eso lo he referenciado.

— Kin Shah

12

Un par de otras opciones son cambiar el nombre de las tablas o, si tienen índices agrupados, puede deshabilitar el índice agrupado.

— Chad Mattox
fuente

Gracias. No sabía que deshabilitar un índice agrupado hace que la tabla sea inutilizable. ¿Cuáles son los pros y los contras de estos enfoques (+ esquema)?

— Tim Schmelter

55

@TimSchmelter una desventaja de deshabilitar el CI es que para habilitarlo nuevamente necesita reconstruir el índice. Otra opción es negar los permisos en la tabla para el rol público, aunque el propietario de la base de datos o los administradores del sistema los verán y posiblemente también a través del encadenamiento de la propiedad.

— Martin Smith

Antes de descartar una tabla o de una columna de una tabla, a menudo le cambio el nombre agregando "_deprecated" o algo así al final del nombre. Entonces, si no hay errores, no debe haber nada que lo haga referencia.

— Jay

Los cambios de permisos son cambiantes. Si la cuenta de servicio que ejecuta una aplicación es dbo, o peor aún, sysadmin, ignorará por completo cualquier tipo de DENY. Esperemos que no lo sean, pero sucede.

— Kenneth Fisher

6

Elimine los permisos de la tabla de Role (s) / Group (s) / Account (s) que [podría] estar usándolo.

Si algo explota, vuelva a colocarlo [rápidamente].

Sugerencia: Usar un script para hacer estos cambios sería una muy, muy buena idea.

— Phill W.
fuente

Como lo haría probar en una base de datos que no sea de producción. ;) Con suerte, eso fue obvio para el OP, sin embargo.

— jpmc26

@ jpmc26. Primero probaré en una base de datos que no sea de producción. Pero el problema es que quiero saber si las funciones u objetos de la base de datos se usan desde el exterior (no solo a través de métodos de servicio web sino también directamente en la base de datos o las herramientas de administración en otras ubicaciones de la empresa).

— Tim Schmelter

Hm. Si está buscando acceso directo a la base de datos mediante DBA, parece que el registro está en orden. Puede que no sea muy probable que vea el mismo uso en prod y no prod del trabajo manual. No estoy realmente seguro de lo fácil que sería registrar estas operaciones, pero si tuviera un producto de inicio de sesión, podría analizarlo para buscar usos.

— jpmc26

@ jpmc26: está bien si esos administradores caen de bruces, lo reportarán. No está bien con los clientes, pero eso se puede verificar en el sistema de prueba antes de la implementación.

— Tim Schmelter

3

Por lo general, eliminar permisos no va a funcionar porque no puedes estar SEGURO de que alguien no tiene permisos. Posiblemente a través de un grupo, rol o incluso porque son administradores de sistemas (aunque esperemos que no).

Para las tablas que puede desactivarlas. Y ese es un proceso rápido. Sin embargo, habilitarlos requiere que los reconstruya y para una tabla grande que podría llevarle bastante tiempo.

Su mejor opción será mover el objeto a un nuevo esquema (como sugirió) o renombrar el objeto. Ambas operaciones son rápidas y fáciles de hacer y deshacer. Los permisos también permanecerán en su lugar en ambas direcciones.

Un paso adicional que puede tomar es agregar una "nota TBD" en las propiedades extendidas del objeto. Puede anotar cuándo realizó el cambio y / o cualquier nota que pueda tener sobre por qué cree que es seguro deshacerse de él.

Dicho todo esto, ejecutaría una sesión de eventos extendida (o seguimiento del generador de perfiles) durante unos días para asegurarme de que tiene todos los objetos en uso. Puede limitar la sesión a solo el nombre del objeto y cuando se tocó para reducir la sobrecarga. También asegúrese de ejecutar esta sesión durante unos días a cada lado del final del mes y posiblemente incluso al final del trimestre para asegurarse de tener todo.

— Kenneth Fisher
fuente

3

Elimine los permisos como sugiere Phil W.

También elimine los permisos de cualquier procedimiento almacenado que use las tablas. En SQL Server, los permisos (no sé de otros) se encadenan desde un objeto que llama (por ejemplo, el procedimiento almacenado) al objeto llamado (por ejemplo, una tabla).

— Peter Bill
fuente

La tarea consistía en dejar que todas las herramientas, funciones, objetos, consultas (incluso en bases de datos remotas) fallaran al intentar acceder a estas tablas. Si tengo que modificar un procedimiento almacenado, ya tengo que saber que lo usa. ¿O hay alguna forma simple de determinar que una tabla es utilizada por un procedimiento almacenado?

— Tim Schmelter

No sugerí modificar el procedimiento almacenado, solo eliminar su permiso EJECUTAR. Como usted dice, es fácil restaurar el permiso si es necesario. Puede ver qué tablas utiliza un procedimiento almacenado: en SQL Server Management Studio, Object Explorer, seleccione su base de datos -> Programabilidad -> Procedimientos almacenados. Haga clic con el botón derecho en un nombre de sproc y elija Ver dependencias. Seleccione objetos de los que depende [nombre de sproc].

— Peter Bill