Sicurezza, accesso e operazioni per le migrazioni di Teradata

Questo articolo è la terza parte di una serie in sette parti che offre indicazioni su come eseguire la migrazione da Teradata ad Azure Synapse Analytics. Questo articolo si incentra sulle procedure consigliate per le operazioni di accesso alla sicurezza.

Considerazioni sulla sicurezza

Questo articolo illustra i metodi di connessione per gli ambienti di Teradata legacy esistenti e il modo in cui è possibile eseguirne la migrazione ad Azure Synapse Analytics con un rischio e un impatto sull'utente minimi.

Questo articolo presuppone che sia necessario eseguire la migrazione dei metodi di connessione esistenti e della struttura di utente/ruolo/autorizzazione così come sono. Altrimenti, usare il portale di Azure per creare e gestire un nuovo regime di sicurezza.

Per altre informazioni sulle opzioni di sicurezza di Azure Synapse, vedere il white paper sulla sicurezza.

Connessione e autenticazione

Opzioni di autorizzazione di Teradata

Suggerimento

L'autenticazione sia in Teradata che in Azure Synapse può essere eseguita "nel database" o tramite metodi esterni.

Teradata supporta diversi meccanismi per la connessione e l'autorizzazione. I valori validi del meccanismo sono:

• TD1, che seleziona Teradata 1 come meccanismo di autenticazione. Nome utente e password sono obbligatori.

• TD2, che seleziona Teradata 2 come meccanismo di autenticazione. Nome utente e password sono obbligatori.

• TDNEGO, che seleziona automaticamente uno dei meccanismi di autenticazione in base al criterio, senza coinvolgimento dell'utente.

• LDAP, che seleziona Lightweight Directory Access Protocol (LDAP) come meccanismo di autenticazione. L'applicazione indica il nome utente e la password.

• KRB5, che seleziona Kerberos (KRB5) nei client Windows che utilizzano i server Windows. Per accedere usando KRB5, l'utente deve fornire un dominio, un nome utente e una password. Il dominio viene specificato impostando il nome utente su MyUserName@MyDomain.

• NTLM, che seleziona NTLM nei client Windows che utilizzano server Windows. L'applicazione indica il nome utente e la password.

Kerberos (KRB5), Kerberos Compatibility (KRB5C), NT LAN Manager (NTLM) e Nt LAN Manager Compatibility (NTLMC) sono solo per Windows.

Opzioni di autorizzazione di Azure Synapse

Azure Synapse supporta due opzioni di base per la connessione e l'autorizzazione:

• Autenticazione SQL: l'autenticazione SQL viene eseguita tramite una connessione alle banche dati che include un identificatore del database, un ID utente e una password oltre ad altri parametri facoltativi. Ciò equivale funzionalmente a Teradata TD1, TD2 e alle connessioni predefinite.

• Autenticazione di Microsoft Entra: con l'autenticazione di Microsoft Entra è possibile gestire centralmente le identità degli utenti del database e altri servizi Microsoft in un'unica posizione centrale. La gestione centrale degli ID consente di gestire gli utenti di SQL Data Warehouse in un'unica posizione e semplifica la gestione delle autorizzazioni. Microsoft Entra ID può anche supportare le connessioni ai servizi LDAP e Kerberos, ad esempio, Microsoft Entra ID può essere usato per connettersi alle directory LDAP esistenti se devono rimanere attive dopo la migrazione del database.

Utenti, ruoli e autorizzazioni

Panoramica

Suggerimento

La pianificazione generale è essenziale per un progetto di migrazione ottimale.

Sia Teradata che Azure Synapse implementano il controllo di accesso al database tramite una combinazione di utenti, ruoli e autorizzazioni. Entrambi usano istruzioni SQL CREATE USER e CREATE ROLE standard per definire utenti e ruoli e istruzioni GRANT e REVOKE per assegnare o rimuovere autorizzazioni a tali utenti e/o ruoli.

Suggerimento

È consigliabile eseguire l'automazione dei processi di migrazione per ridurre il tempo trascorso e l'ambito degli errori.

Concettualmente i due database sono simili e potrebbe essere possibile automatizzare la migrazione di ID utente, ruoli e autorizzazioni esistenti in qualche modo. Eseguire la migrazione di tali dati estraendo le informazioni esistenti sull'utente e sul ruolo legacy dalle tabelle del catalogo del sistema Teradata e generando istruzioni CREATE USER e CREATE ROLE equivalenti e corrispondenti da eseguire in Azure Synapse per ricreare la stessa gerarchia utente/ruolo.

Dopo l'estrazione dei dati, usare le tabelle del catalogo di sistema Teradata per generare istruzioni GRANT equivalenti per assegnare le autorizzazioni (dove esiste un'istruzione equivalente). Il diagramma seguente illustra come usare i metadati esistenti per generare il codice SQL necessario.

Utenti e ruoli

Suggerimento

La migrazione di un data warehouse richiede molto più di semplici tabelle, viste e istruzioni SQL.

Le informazioni sugli utenti e i ruoli correnti in un sistema Teradata sono disponibili nelle tabelle del catalogo di sistema DBC.USERS (o DBC.DATABASES) e DBC.ROLEMEMBERS. Eseguire una query su queste tabelle (se l'utente ha accesso SELECT a tali tabelle) per ottenere gli elenchi correnti di utenti e ruoli definiti all'interno del sistema. Di seguito sono riportati esempi di query per eseguire questa operazione per singoli utenti:

/***SQL to find all users***/
SELECT
DatabaseName AS UserName
FROM DBC.Databases
WHERE dbkind = 'u';

/***SQL to find all roles***/
SELECT A.ROLENAME, A.GRANTEE, A.GRANTOR,
  A.DefaultRole, 
  A.WithAdmin,
  B.DATABASENAME, 
  B.TABLENAME,
  B.COLUMNNAME, 
  B.GRANTORNAME,
  B.AccessRight
FROM DBC.ROLEMEMBERS A 
JOIN DBC.ALLROLERIGHTS B 
ON A.ROLENAME = B.ROLENAME 
GROUP BY 1,2,3,4,5,6,7
ORDER BY 2,1,6;

Questi esempi modificano le istruzioni SELECT per produrre un set di risultati, ovvero una serie di istruzioni CREATE USER e CREATE ROLE, includendo il testo appropriato come valore letterale all'interno dell'istruzione SELECT.

Non è possibile recuperare le password esistenti, quindi è necessario implementare uno schema per allocare nuove password iniziali in Azure Synapse.

Autorizzazioni

Suggerimento

Esistono autorizzazioni equivalenti di Azure Synapse per operazioni di database di base, ad esempio DML e DDL.

In un sistema Teradata, le tabelle di sistema DBC.ALLRIGHTS e DBC.ALLROLERIGHTS contengono i diritti di accesso per utenti e ruoli. Eseguire una query su queste tabelle (se l'utente ha accesso SELECT a tali tabelle) per ottenere gli elenchi correnti dei diritti di accesso definiti all'interno del sistema. Di seguito sono riportati esempi di query per singoli utenti:

/**SQL for AccessRights held by a USER***/
SELECT UserName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantAuthority, GrantorName, AllnessFlag, CreatorName, CreateTimeStamp
FROM DBC.ALLRIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE UserName='UserXYZ'
Order By 2,3,4,5;

/**SQL for AccessRights held by a ROLE***/
SELECT RoleName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantorName, CreateTimeStamp
FROM DBC.ALLROLERIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv
Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE RoleName='BI_DEVELOPER'
Order By 2,3,4,5;

Modificare queste istruzioni SELECT di esempio per produrre un set di risultati costituito da una serie di istruzioni GRANT includendo il testo appropriato come valore letterale all'interno dell'istruzione SELECT.

Usare la tabella AccessRightsAbbv per cercare il testo completo del diritto di accesso, perché la chiave di join è un campo abbreviato 'type'. Per un elenco dei diritti di accesso di Teradata e dei loro equivalenti in Azure Synapse, vedere le tabelle seguenti.

Nome dell'autorizzazione Teradata	Tipo Teradata	Equivalente di Azure Synapse
ABORT SESSION	AS	KILL DATABASE CONNECTION
ALTER EXTERNAL PROCEDURE	AE	4
ALTER FUNCTION	AF	ALTER FUNCTION
ALTER PROCEDURE	AP	ALTER PROCEDURE
CHECKPOINT	CP	CHECKPOINT
CREATE AUTHORIZATION	CA	CREATE LOGIN
CREATE DATABASE	CD	CREATE DATABASE
CREATE EXTERNAL PROCEDURE	CE	4
CREATE FUNCTION	CF	CREATE FUNCTION
CREATE GLOP	GC	3
CREATE MACRO	CA	CREATE PROCEDURE 2
CREATE OWNER PROCEDURE	OP	CREATE PROCEDURE
CREATE PROCEDURE	PC	CREATE PROCEDURE
CREATE PROFILE	CO	CREATE LOGIN 1
CREATE ROLE	CR	CREATE ROLE
DROP DATABASE	DD	DROP DATABASE
DROP FUNCTION	DF	DROP FUNCTION
DROP GLOP	GD	3
DROP MACRO	DM	DROP PROCEDURE 2
DROP PROCEDURE	PD	DELETE PROCEDURE
DROP PROFILE	DO	DROP LOGIN 1
DROP ROLE	DR	DELETE ROLE
DROP TABLE	DT	DROP TABLE
DROP TRIGGER	DG	3
DROP USER	DU	DROP USER
DROP VIEW	DV	DROP VIEW
DUMP	Punto di distribuzione (DP)	4
EXECUTE	E	EXECUTE
EXECUTE FUNCTION	EF	EXECUTE
EXECUTE PROCEDURE	PE	EXECUTE
GLOP MEMBER	GM	3
INDEX	IX	CREATE INDEX
INSERT …	I	INSERT
MONRESOURCE	MR	5
MONSESSION	MS	5
OVERRIDE DUMP CONSTRAINT	OA	4
OVERRIDE RESTORE CONSTRAINT	OPPURE	4
REFERENCES	RF	REFERENCES
REPLCONTROL	RO	5
RESTORE	RS	4
SELECT	R	SELECT
SETRESRATE	SR	5
SETSESSRATE	Server del sito (SS)	5
SHOW	SH	3
UPDATE	U	UPDATE

AccessRightsAbbv Note della tabella:

1. PROFILE di Teradata equivale a LOGIN in Azure Synapse.

2. Nella tabella seguente vengono riepilogate le differenze tra macro e stored procedure in Teradata. In Azure Synapse le procedure offrono le funzionalità descritte nella tabella.

   Macro	Stored procedure
   Contiene SQL	Contiene SQL
   Può contenere comandi dot BTEQ	Contiene SPL completo
   Può ricevere i valori dei parametri passati	Può ricevere i valori dei parametri passati
   Può recuperare una o più righe	È necessario usare un cursore per recuperare più righe
   Archiviato nello spazio DBC PERM	Archiviato in DATABASE o USER PERM
   Restituisce righe al client	Può restituire uno o più valori al client come parametri

3. SHOW, GLOP e TRIGGER non hanno equivalenti diretti in Azure Synapse.

4. Queste funzioni vengono gestite automaticamente dal sistema in Azure Synapse. Vedere Considerazioni operative.

5. In Azure Synapse queste funzionalità vengono gestite all'esterno del database.

Per altre informazioni sui diritti di accesso in Azure Synapse, vedere Autorizzazioni di sicurezza di Azure Synapse Analytics.

Considerazioni operative

Suggerimento

Le attività operative sono necessarie per mantenere efficiente il funzionamento di qualsiasi data warehouse.

Questa sezione illustra come implementare attività operative di Teradata tipiche in Azure Synapse con un rischio e un impatto sugli utenti minimi.

Come per tutti i prodotti del data warehouse, una volta in produzione sono necessarie attività di gestione che vengono svolte per mantenere il sistema in esecuzione in modo efficiente e offrire dati per il monitoraggio e il controllo. Anche l'utilizzo delle risorse e la pianificazione della capacità per una crescita futura rientrano in questa categoria, come il backup/ripristino dei dati.

Anche se concettualmente le attività di gestione e operative per data warehouse diversi sono simili, le singole implementazioni possono differire. In generale, i moderni prodotti basati sul cloud, ad esempio Azure Synapse, tendono a incorporare un approccio più automatizzato e "gestito dal sistema" (anziché un approccio più "manuale" nei data warehouse legacy, come Teradata).

Le sezioni seguenti confrontano le opzioni di Teradata e Azure Synapse per varie attività operative.

Attività di manutenzione

Suggerimento

Le attività di manutenzione mantengono efficiente l'operatività di un warehouse di produzione e ottimizzano l'uso di risorse come l'archiviazione.

Nella maggior parte degli ambienti di data warehouse legacy è necessario eseguire normali attività di "manutenzione", ad esempio il recupero dello spazio di archiviazione su disco che può essere liberato rimuovendo le versioni precedenti di righe aggiornate o eliminate o riorganizzando i file di log di dati o i blocchi di indice per una maggiore efficienza. Anche la raccolta di statistiche è un'attività potenzialmente dispendiosa in termini di tempo. La raccolta di statistiche è necessaria dopo un inserimento di dati in blocco per offrire a Query Optimizer dati aggiornati per la generazione di base dei piani di esecuzione delle query.

Teradata consiglia di raccogliere le statistiche nel modo seguente:

• Raccogliere statistiche sulle tabelle non popolate per configurare l'istogramma di intervalli usato nell'elaborazione interna. Questa raccolta iniziale rende più veloci le raccolte di statistiche successive. Assicurarsi di raccogliere nuovamente le statistiche dopo l'aggiunta dei dati.

• Raccogliere le statistiche sulle fasi del prototipo per le tabelle appena popolate.

• Raccogliere statistiche sulle fasi di produzione dopo aver apportato una percentuale significativa di modifica alla tabella o alla partizione (~10% delle righe). Per volumi elevati di valori non univoci, ad esempio date o timestamp, può essere vantaggioso raccogliere nuovamente il 7%.

• Raccogliere le statistiche sulle fasi di produzione dopo aver creato gli utenti e applicato caricamenti di query reali al database (fino a circa tre mesi di query).

• Raccogliere statistiche nelle prime settimane dopo un aggiornamento o una migrazione durante i periodi di basso utilizzo della CPU.

La raccolta di statistiche può essere gestita manualmente usando le API aperte di Gestione statistiche automatizzate o automaticamente tramite il portlet Teradata Viewpoint Stats Manager.

Suggerimento

Automatizzare e monitorare le attività di manutenzione in Azure.

Il database di Teradata contiene molte tabelle di log nel dizionario dei dati che accumulano dati, automaticamente o dopo l'abilitazione di determinate funzionalità. Poiché i dati di log aumentano nel tempo, eliminare le informazioni meno recenti per evitare di usare spazio permanente. Sono disponibili opzioni per automatizzare la manutenzione di questi log. Le tabelle del dizionario Teradata che richiedono la manutenzione vengono illustrate di seguito.

Tabelle del dizionario da gestire

Reimpostare accumulatori e valori di picco tramite la vista DBC.AMPUsage e la macro ClearPeakDisk offerta con il software:

• DBC.Acctg: utilizzo delle risorse per account/utente

• DBC.DataBaseSpace: contabilità dello spazio di database e tabella

Teradata gestisce automaticamente queste tabelle, ma le procedure consigliate possono ridurre le dimensioni:

• DBC.AccessRights: diritti utente per gli oggetti

• DBC.RoleGrants: diritti di ruolo per gli oggetti

• DBC.Roles: ruoli definiti

• DBC.Accounts: codici account per utente

Archiviare queste tabelle di registrazione (se necessario) ed eliminare le informazioni di 60-90 giorni prima. La conservazione dipende dai requisiti dei clienti:

• DBC.SW_Event_Log: log della console di database

• DBC.ResUsage: tabelle di monitoraggio delle risorse

• DBC.EventLog: cronologia di accesso/disconnessione della sessione

• DBC.AccLogTbl: eventi utente/oggetto registrati

• DBC.DBQL tables: attività utente/SQL registrata

• .NETSecPolicyLogTbl: audit trail dei criteri di sicurezza dinamici registrati

• .NETSecPolicyLogRuleTbl: controlla quando e come vengono registrati i criteri di sicurezza dinamici

Eliminare queste tabelle quando il supporto rimovibile associato è scaduto e sovrascritto:

• DBC.RCEvent: eventi di archivio/ripristino

• DBC.RCConfiguration: configurazione di archivio/ripristino

• DBC.RCMedia: VolSerial per l'archivio/ripristino

Azure Synapse offre un'opzione per creare automaticamente le statistiche in modo che possano essere usate in base alle esigenze. Eseguire manualmente la deframmentazione di indici e blocchi di dati, in base a una pianificazione o in modo automatico. L'uso delle funzionalità predefinite native di Azure può ridurre il lavoro richiesto in un esercizio di migrazione.

Monitoraggio e controllo

Suggerimento

Nel corso del tempo sono stati implementati diversi strumenti per consentire il monitoraggio e la registrazione dei sistemi Teradata.

Teradata offre diversi strumenti per monitorare l'operazione, tra cui Teradata Viewpoint e Ecosystem Manager. Per la registrazione della cronologia delle query, il log query del database (DBQL) è una funzionalità di database Teradata che offre una serie di tabelle predefinite in grado di archiviare i record cronologici delle query e la relativa durata, le prestazioni e le attività di destinazione in base a regole definite dall'utente.

Gli amministratori di database possono usare Teradata Viewpoint per determinare lo stato del sistema, le tendenze e lo stato delle singole query. Osservando le tendenze nell'utilizzo del sistema, gli amministratori di sistema sono in grado di pianificare meglio le implementazioni del progetto, i processi batch e la manutenzione per evitare periodi di picco di uso. Gli utenti aziendali possono usare Teradata Viewpoint per accedere rapidamente allo stato dei report e delle query ed eseguire il drill-down nei dettagli.

Suggerimento

Il portale di Azure offre un'interfaccia utente per gestire le attività di monitoraggio e controllo per tutti i dati e i processi di Azure.

Analogamente, Azure Synapse offre una ricca esperienza di monitoraggio nel portale di Azure per assicurare informazioni dettagliate sul carico di lavoro del data warehouse. Il portale di Azure è lo strumento consigliato per il monitoraggio del data warehouse, in quanto fornisce periodi di conservazione, avvisi, raccomandazioni, grafici personalizzabili, nonché dashboard di metriche e log configurabili.

Il portale consente inoltre l'integrazione con altri servizi di monitoraggio di Azure come Operations Management Suite (OMS) e Monitoraggio di Azure (log) per offrire un'esperienza di monitoraggio olistica non solo per il data warehouse, ma anche per l'intera piattaforma analitica di Azure per un'esperienza di monitoraggio integrata.

Suggerimento

Le metriche di basso livello e a livello di sistema vengono registrate automaticamente in Azure Synapse.

Le statistiche di utilizzo delle risorse per Azure Synapse vengono registrate automaticamente all'interno del sistema. Le metriche per ogni query includono statistiche di utilizzo per CPU, memoria, cache, I/O e un'area di lavoro temporanea, nonché informazioni di connettività come tentativi di connessione non riusciti.

Azure Synapse offre un set di Dynamic Management Views (DMV). Queste viste sono utili durante la risoluzione dei problemi e l'identificazione dei colli di bottiglia nelle prestazioni con il carico di lavoro.

Per altre informazioni, consultare le opzioni di gestione e per le operazioni di Azure Synapse.

Disponibilità elevata e ripristino di emergenza

Teradata implementa funzionalità come FALLBACKl'utilità Archive Restore Copy (ARC) e Data Stream Architecture (DSA) per garantire la protezione dalla perdita di dati e dalla disponibilità elevata tramite la replica e l'archivio dei dati. Le opzioni di ripristino di emergenza includono la doppia soluzione attiva, il ripristino di emergenza come servizio o un sistema di sostituzione a seconda dei requisiti di tempo di ripristino.

Suggerimento

Azure Synapse crea automaticamente snapshot per garantire tempi di ripristino rapidi.

Azure Synapse usa gli snapshot del database per offrire disponibilità elevata del warehouse. Uno snapshot del data warehouse crea un punto di ripristino che è possibile usare per copiare il data warehouse o ripristinarlo a uno stato precedente. Poiché Azure Synapse è un sistema distribuito, uno snapshot del data warehouse è costituito da molti file che si trovano in Archiviazione di Azure. Gli snapshot acquisiscono le modifiche incrementali dai dati archiviati nel data warehouse.

Azure Synapse acquisisce automaticamente gli snapshot nell'arco della giornata per creare punti di ripristino che sono disponibili per sette giorni. La durata di questo periodo di conservazione non può essere modificata. Azure Synapse supporta un obiettivo del punto di ripristino (RPO) di otto ore. È possibile ripristinare un data warehouse nell'area primaria da uno qualsiasi degli snapshot acquisiti negli ultimi sette giorni.

Suggerimento

Usare snapshot definiti dall'utente per definire un punto di ripristino prima degli aggiornamenti delle chiavi.

Sono supportati anche i punti di ripristino definiti dall'utente, consentendo l'attivazione manuale degli snapshot per creare punti di ripristino di un data warehouse prima e dopo modifiche di grandi dimensioni. Questa funzionalità garantisce la coerenza logica dei punti di ripristino, offrendo così una protezione dei dati aggiuntiva in caso di eventuali interruzioni del carico di lavoro o di errori dell'utente per ottenere un RPO inferiore a 8 ore.

Suggerimento

Microsoft Azure offre backup automatici in una posizione geografica separata per abilitare il ripristino di emergenza.

Oltre agli snapshot descritti in precedenza, Azure Synapse esegue anche come operazione standard un backup geografico una volta al giorno in un data center associato. L'obiettivo del punto di ripristino per un ripristino geografico è di 24 ore. È possibile ripristinare il backup geografico in un server in qualsiasi altra area in cui sia supportato Azure Synapse. Un backup geografico garantisce che un data warehouse possa essere ripristinato nel caso in cui i punti di ripristino nell'area primaria non siano disponibili.

Gestione dei carichi di lavoro

Suggerimento

In un data warehouse di produzione sono in genere presenti carichi di lavoro misti con diverse caratteristiche di utilizzo delle risorse in esecuzione simultaneamente.

Un carico di lavoro è una classe di richieste di database con tratti comuni il cui accesso al database può essere gestito con un set di regole. I carichi di lavoro sono utili per:

• Impostare priorità di accesso diverse per diversi tipi di richieste.

• Monitorare i modelli di utilizzo delle risorse, l'ottimizzazione delle prestazioni e la pianificazione della capacità.

• Limitare il numero di richieste o sessioni che possono essere eseguite contemporaneamente.

In un sistema Teradata, la gestione del carico di lavoro è l'atto di gestire le prestazioni del carico di lavoro monitorando l'attività del sistema e operando quando vengono raggiunti i limiti predefiniti. La gestione del carico di lavoro usa regole e ogni regola si applica solo ad alcune richieste di database. Tuttavia, la raccolta di tutte le regole si applica a tutto il lavoro attivo sulla piattaforma. Teradata Active System Management (TASM) esegue la gestione completa del carico di lavoro in un database Teradata.

In Azure Synapse, le classi di risorse sono limiti delle risorse predeterminati che regolano le risorse di calcolo e la concorrenza per l'esecuzione delle query. Le classi di risorse possono agevolare la gestione del carico di lavoro, consentendo di impostare limiti per il numero di query eseguite contemporaneamente e per le risorse di calcolo assegnate a ogni query. È necessario trovare il giusto compromesso tra memoria e concorrenza.

Azure Synapse registra automaticamente le statistiche di utilizzo delle risorse. Le metriche includono statistiche di utilizzo per CPU, memoria, cache, I/O e area di lavoro temporanea per ogni query. Azure Synapse registra anche le informazioni di connettività, ad esempio i tentativi di connessione non riusciti.

Suggerimento

Le metriche di basso livello e a livello di sistema vengono registrate automaticamente in Azure.

Azure Synapse supporta questi concetti di base relativi alla gestione dei carichi di lavoro:

• Classificazione del carico di lavoro: è possibile assegnare una richiesta a un gruppo di carico di lavoro per impostare i livelli di importanza.

• Importanza del carico di lavoro: è possibile influire sull'ordine in cui una richiesta ottiene l'accesso alle risorse. Per impostazione predefinita, le query vengono rilasciate dalla coda in base alla modalità first-in, first-out man mano che le risorse diventano disponibili. L'importanza del carico di lavoro consente alle query con priorità maggiore di ricevere immediatamente le risorse indipendentemente dalla coda.

• Isolamento del carico di lavoro: è possibile riservare le risorse per un gruppo di carico di lavoro, assegnare un utilizzo massimo e minimo per risorse variabili, limitare le risorse che un gruppo di richieste può utilizzare e impostare un valore di timeout per terminare automaticamente le query con eccessivo tempo di esecuzione.

L'esecuzione di carichi di lavoro misti può causare problemi di risorse nei sistemi sovraccarichi. Uno schema corretto di gestione del carico di lavoro comporta una gestione efficace delle risorse, ne assicura l'utilizzo altamente efficiente e massimizza il ritorno sugli investimenti. La classificazione del carico di lavoro, l'importanza del carico di lavoro e l'isolamento del carico di lavoro offrono un maggiore controllo sul modo in cui il carico di lavoro usa le risorse di sistema.

La guida alla gestione dei carichi di lavoro descrive le tecniche per analizzare il carico di lavoro, gestire e monitorare l'importanza del carico di lavoro](../../sql-data-warehouse/sql-data-warehouse-how-to-manage-and-monitor-workload-importance.md) e i passaggi per convertire una classe di risorse in un gruppo di carico di lavoro. Usare il portale di Azure e le query T-SQL in DMV per monitorare il carico di lavoro e garantire che le risorse applicabili vengano usate in modo efficiente. Azure Synapse offre un set di DMV (Dynamic Management Views) per il monitoraggio di tutti gli aspetti della gestione dei carichi di lavoro. Queste viste sono utili durante l'attiva risoluzione dei problemi e l'identificazione dei colli di bottiglia delle prestazioni nel carico di lavoro.

Queste informazioni possono essere usate anche per la pianificazione della capacità, determinando le risorse necessarie per altri utenti o carichi di lavoro dell'applicazione. Questo vale anche per la pianificazione della scalabilità/riduzione delle risorse di calcolo per il supporto conveniente dei carichi di lavoro "di picco".

Per altre informazioni sulla gestione dei carichi di lavoro in Azure Synapse, vedere Gestione del carico di lavoro con le classi di risorse.

Ridimensionare le prestazioni

Suggerimento

Un vantaggio importante di Azure è la possibilità di aumentare e ridurre in modo indipendente le prestazioni delle risorse di calcolo su richiesta per gestire carichi di lavoro di picco in modo economicamente conveniente.

L'architettura di Azure Synapse separa le risorse di archiviazione e calcolo consentendo di eseguire il dimensionamento per ognuna in modo indipendente. Pertanto, è possibile dimensionare le risorse di calcolo per soddisfare le richieste di prestazioni, a prescindere dalla quantità di dati. È anche possibile sospendere e riprendere le risorse di calcolo. Un vantaggio naturale di questa architettura è che la fatturazione per calcolo e archiviazione è separata. Se un data warehouse non è in uso, è possibile risparmiare sui costi di calcolo sospendo il calcolo.

Le risorse di calcolo possono essere dimensionate aumentandone o riducendone le prestazioni modificando l'impostazione delle unità del data warehouse per il data warehouse. Le prestazioni di caricamento e relative alle query aumentano in modo lineare man mano che si aggiungono più unità di data warehouse.

L'aggiunta di più nodi di calcolo aggiunge maggiore potenza di calcolo e possibilità di sfruttare un maggior numero di elaborazioni parallele. Con l'aumento del numero dei nodi di calcolo si riduce il numero di distribuzioni per ogni nodo di calcolo, con un conseguente incremento della potenza di calcolo e dell'elaborazione parallela per le query. In modo analogo, la diminuzione delle unità di data warehouse riduce il numero di nodi di calcolo e di conseguenza le risorse di calcolo per le query.

Passaggi successivi

Per altre informazioni sulla visualizzazione e la creazione di report, vedere l'articolo successivo di questa serie: Visualizzazione e creazione di report per le migrazioni di Teradata.