Approfondimenti tecnici e articoli di riferimento su SQL Server e Data Platform, con estensioni su Azure, analytics/BI e Data Engineering. Qui trovi guide operative, best practice, analisi e casi reali dalla community UGISS, pensati per essere utili anche a distanza di tempo.
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:
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!
Le potenzialità del framework tSQLt sono state descritte nell’articolo “Il framework tSQLt e l’esecuzione di un test”:
Parameter Sensitive Plan (PSP) Optimization è una delle funzionalità introdotte da SQL Server 2022 e si colloca nella famiglia di funzionalità note con il nome di Intelligent Query Processing che migliorano le prestazioni dei carichi di lavoro esistenti senza modifiche al codice applicativo. Intelligent Query Processing (potenziato anche in SQL Server 2019) è l’erede della precedente tecnologia nota con il nome di Adaptive Query Processing di cui è disponibile il video Query Processing improvements in the latest versions of SQL Server sul canale UGISS di Vimeo.
