Come nascondere / disabilitare le tabelle senza lasciarle cadere per controllare la ridondanza?

12

Devo mantenere ed estendere un vecchio sistema legacy che contiene metodi di webservice e tabelle di database che non vengono più utilizzate. Dato che non sono del tutto sicuro che i tavoli siano davvero ridondanti, ho paura di lasciarli cadere.

Esiste un altro modo per ottenere lo stesso effetto (le tabelle non possono più essere utilizzate) senza lasciarle cadere? La mia idea era quella di trasferirli in un diverso schema (ad esempio, Deleted) dal default corrente, dbo.

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

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

C'è qualche altra opzione o ci sono degli svantaggi nell'approccio dello schema?

— Tim Schmelter
fonte

7

Esiste un altro modo per ottenere lo stesso (le tabelle non possono più essere utilizzate) senza lasciarle cadere?

Una modifica dello schema è un'operazione molto rapida: è necessaria solo la modifica dei metadati. L'idea originale che ho avuto è stata dal blog di Aaron Bertrand - Schema Switch-A-Roo .

Puoi seguire i passaggi dalla mia risposta qui

Ovviamente ci sono altri metodi come sp_rename N'old table ', N'new table' o semplicemente negare le autorizzazioni per la tabella.

— Kin Shah
fonte

Non ero sicuro di quale risposta avrei dovuto accettare perché tutti sono utili. Non conoscevo l'articolo di Aaron, quindi l'ho accettato poiché contiene più informazioni (anche se solo collegate).

— Tim Schmelter,

@TimSchmelter Sono contento che l'abbia trovato utile. Non ha senso ripetere qui l'articolo o la mia risposta (collegata). Ecco perché l'ho fatto riferimento.

— Kin Shah,

12

Un paio di altre opzioni sono solo per rinominare le tabelle o, se hanno indici cluster, è possibile disabilitare l'indice cluster.

— Chad Mattox
fonte

Grazie. Non sapevo che la disabilitazione di un indice cluster rendesse la tabella inutilizzabile. Quali sono i pro e i contro di questi approcci (+ schema)?

— Tim Schmelter,

5

@TimSchmelter un contro di disabilitazione dell'elemento della configurazione è che per abilitarlo nuovamente è necessario ricostruire l'indice. Un'altra opzione è negare le autorizzazioni sulla tabella per il ruolo pubblico sebbene il proprietario del database o gli amministratori di sistema li vedranno ancora e possibilmente anche attraverso il concatenamento della proprietà.

— Martin Smith,

Prima di abbandonare una tabella o di eliminare una colonna da una tabella, la rinomino spesso aggiungendo "_deprecated" o qualcosa del genere alla fine del nome. Quindi se non ci sono errori, non ci deve essere nulla che faccia riferimento a esso.

— Jay,

Le modifiche alle autorizzazioni sono rischiose. Se l'account del servizio che esegue un'applicazione è il dbo, o anche peggio di sysadmin, ignorerà completamente qualsiasi tipo di DENY. Speriamo che non lo siano, ma succede.

— Kenneth Fisher,

6

Rimuovere le autorizzazioni sulla tabella dai ruoli / gruppi / account / account che [potrebbe] usarlo.

Se qualcosa esplode, rimetterli [rapidamente].

Suggerimento: l'utilizzo di uno script per apportare queste modifiche sarebbe davvero un'ottima idea.

— Phill W.
fonte

Come farebbe il test su un database non di produzione. ;) Spero che questo sia ovvio per l'OP, però.

— jpmc26,

@ jpmc26. proverò prima in un database non di produzione. Ma il problema è che voglio sapere se le funzioni o gli oggetti del database vengono utilizzati dall'esterno (non solo tramite i metodi del servizio web, ma anche direttamente sul database o sugli strumenti di amministrazione in altre posizioni dell'azienda).

— Tim Schmelter,

Hm. Se stai cercando l'accesso diretto al DB da parte dei DBA, sembra che la registrazione sia in ordine. Potrebbe non essere molto probabile che vedresti lo stesso utilizzo in prod e non prod da lavoro manuale. Non sono davvero sicuro di quanto sarebbe facile registrare queste operazioni, ma se avessi un prod di accesso, potresti analizzarlo per cercare gli usi.

— jpmc26,

@ jpmc26: va bene se quegli amministratori cadono in faccia, lo segnaleranno. Non va bene con i clienti, ma questo può essere verificato sul sistema di test prima dell'implementazione.

— Tim Schmelter,

3

La rimozione delle autorizzazioni generalmente non funzionerà perché non si può essere certi che qualcuno non disponga delle autorizzazioni. Forse attraverso un gruppo, un ruolo o anche perché sono amministratori di sistema (anche se speriamo di no).

Per le tabelle puoi disabilitarle. E questo è un processo rapido. Tuttavia per abilitarli è necessario ricostruirli e per una tabella di grandi dimensioni che potrebbe richiedere del tempo.

La tua scommessa migliore sarà quella di spostare l'oggetto in un nuovo schema (come hai suggerito) o rinominare l'oggetto. Entrambe queste operazioni sono facili e veloci sia da fare che da annullare. Le autorizzazioni rimarranno attive anche in entrambe le direzioni.

Un ulteriore passo che puoi fare è aggiungere una "nota TBD" nelle proprietà estese dell'oggetto. Puoi prendere nota di quando hai apportato la modifica e / o eventuali note che potresti avere sul perché ritieni che sia sicuro sbarazzarsi di.

Detto questo, avrei eseguito una sessione di eventi estesa (o traccia del profiler) per alcuni giorni per essere sicuro di avere tutti gli oggetti utilizzati. È possibile limitare fortemente la sessione al solo nome dell'oggetto e quando è stata toccata per ridurre il sovraccarico. Assicurati inoltre di eseguire questa sessione per alcuni giorni su entrambi i lati della fine del mese e possibilmente anche alla fine del trimestre per essere sicuro di avere tutto.

— Kenneth Fisher
fonte

3

Rimuovi le autorizzazioni come suggerisce Phil W.

Rimuovere anche le autorizzazioni da qualsiasi stored procedure che utilizza le tabelle. In SQL Server, le autorizzazioni (non conosco altri) sono concatenate da un oggetto chiamante (ad esempio la procedura memorizzata) all'oggetto chiamato (ad esempio una tabella).

— Peter Bill
fonte

L'obiettivo era lasciare che tutti gli strumenti, le funzioni, gli oggetti, le query (anche nei database remoti) fallissero che tentassero di accedere a queste tabelle. Se devo modificare una procedura memorizzata, devo già sapere che la utilizza. Oppure esiste un modo semplice per determinare che una tabella viene utilizzata da una procedura memorizzata?

— Tim Schmelter,

Non ho suggerito di modificare la procedura memorizzata, rimuovendo solo la sua autorizzazione EXECUTE. Come dici tu, è facile ripristinare l'autorizzazione se necessario. È possibile visualizzare quali tabelle vengono utilizzate da una procedura memorizzata: In SQL Server Management Studio, Esplora oggetti, selezionare il database -> Programmabilità -> Stored procedure. Fare clic con il tasto destro del mouse sul nome di uno sproc e selezionare Visualizza dipendenze. Selezionare gli oggetti da cui dipende [nome sproc].

— Peter Bill,