Articoli

Recentemente, ho avuto l’occasione di configurare un piano di manutenzione database per un DB in cui sono state create alcune External Table PolyBase che permettono di raggiungere dati archiviati all’esterno dell’istanza SQL Server.

Non si poteva testare la manutenzione database contestualmente alla configurazione del piano e così ho atteso la finestra temporale dedicata a queste attività. All’ora indicata, il piano di manutenzione (configurazione classica) non è stato eseguito correttamente, le verifiche hanno successivamente rilevato un errore nel task di aggiornamento statistiche.

Nel precedente articolo SQL Server Transparent Data Encryption, il secondo di questa serie di articoli dedicati alle funzionalità di Encryption di SQL Server, abbiamo descritto come per proteggere i dati crittografandoli a livello di I/O, quando sono a riposo.

Questo articolo presenta una introduzione ad un’altra funzionalità di crittografia, nota in un primo momento con il nome di Column Encryption, e successivamente rinominata in Always Encrypted.

Recentemente ho avuto la necessità di dover effettuare il reseed a 1 dei valori di tutte le colonne Identity delle tabelle vuote di un database.

Scomponendo la richiesta in task più piccoli si sono individuati i seguenti due task:

1. Individuare le tabelle senza record nel database
2. Effettuare il reseed dell’unica colonna IDENTITY generando uno script con i comandi incapsulando il codice all’interno di una stored procedure

Per individuare le tabelle prive di righe può essere utilizzata la CTE spaceused sviluppata nell’articolo:

Nel precedente articolo SQL Server Backup Encryption, il primo di questa serie di articoli dedicati alle funzionalità di Encryption di SQL Server, abbiamo descritto come implementare la crittografia nella propria strategia di backup. In questo articolo descriveremo un’altra funzionalità di crittografia dei dati, la Transparent Data Encryption.

Transparent Data Encryption (TDE) è stata introdotta in SQL Server 2008 per proteggere i dati crittografandoli a livello di I/O, si parla quindi di crittografica dei dati a riposo. Transparent Data Encryption crittografa i file fisici, sia i file di dati (.mdf, .ndf) che il file di log (.ldf) mentre i dati effettivi archiviati all’interno del database non vengono crittografati.

I database aziendali rappresentano il luogo in cui le informazioni sono memorizzate per guidare i processi produttivi dell’azienda. Tera di dati, decine di database, milioni di righe, l’intera attività dipende da questo e la sicurezza delle informazioni non può più essere un optional, si parla quindi di sicurezza by design e sicurezza by default.

Nel precedente articolo Data masking con sqlcmdcli abbiamo trattato il tema complesso dell’anonimizzazione dei dati quando si deve prelevare un database di produzione per effettuare test in ambiente di sviluppo anche all’esterno del perimetro aziendale del cliente. Una possibile soluzione è quella di mascherare i dati sensibili su una copia del database di produzione chiedendo al cliente di effettuare le opportune verifiche prima di darci l’autorizzazione definitiva a prelevare la copia dei dati anonimizzata.

Nell’articolo precedente, il terzo di questa serie, abbiamo descritto come scrivere ed eseguire manualmente una unit di test per un trigger! In questo articolo verrà descritto come automatizzare il test di uno o più oggetti SQL Server utilizzando tSQLt, Docker e GitHub Actions!

Tecnologie e framework utilizzati

Le potenzialità del framework tSQLt sono state descritte nell’articolo “Il framework tSQLt e l’esecuzione di un test”: