Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Caricamento dei dati in Amazon Redshift
Sono disponibili diversi modi per caricare i dati in un database Amazon Redshift. Una delle origini di dati popolari da caricare sono i file Amazon S3. Nella tabella seguente sono riepilogati alcuni dei metodi da utilizzare con l’avvio da un’origine Amazon S3.
| Metodo da usare | Description | Quando è necessario un metodo |
| --- | --- | --- |
| COPY command (Comando COPY) | Esegue un’importazione di file in batch per caricare i dati dai file Amazon S3. Questo metodo sfrutta le funzionalità di elaborazione parallela di Amazon Redshift. Per ulteriori informazioni, consulta [Caricamento delle tabelle con il comando COPY](t_Loading_tables_with_the_COPY_command.md). | Utilizzalo quando sono necessari requisiti di base per il caricamento dei dati per avviare manualmente l’importazione di file in batch. Questo metodo viene usato principalmente con pipeline di importazione di file personalizzate e di terze parti o carichi di lavoro di importazione di file una tantum o ad hoc. |
| Comando COPY... CREATE JOB (copia automatica) | Esegue automaticamente i comandi COPY quando viene creato un nuovo file nei percorsi monitorati di Amazon S3. Per ulteriori informazioni, consulta [Creare un’integrazione di eventi S3 per copiare automaticamente i file dai bucket Amazon S3](loading-data-copy-job.md). | Utilizzalo quando una pipeline di importazione di file deve importare automaticamente i dati quando viene creato un nuovo file in Amazon S3. Amazon Redshift consente di tenere traccia dei file importati per prevenire la duplicazione dei dati. Questo metodo richiede la configurazione da parte dei proprietari di bucket Amazon S3. |
| Caricamento da query sui data lake | Crea tabelle esterne per eseguire query sui data lake per i file Amazon S3, quindi esegui il comando INSERT INTO per caricare i risultati delle query sui data lake nelle tabelle locali. Per ulteriori informazioni, consulta [Tabelle esterne per Redshift Spectrum](c-spectrum-external-tables.md). | Utilizzalo in uno dei seguenti scenari: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/t_Loading_data.html) |
| Altri metodi da prendere in considerazione |
| Importazione di dati in streaming | L’importazione in streaming comporta l’importazione a bassa latenza e ad alta velocità di dati del flusso dal flusso di dati Amazon Kinesis e da Streaming gestito da Amazon per Apache Kafka in una vista materializzata con provisioning Amazon Redshift o una vista materializzata Redshift serverless. Per ulteriori informazioni, consultare [Nozioni di base sull'importazione dati in streaming da Amazon Kinesis Data Streams](materialized-view-streaming-ingestion-getting-started.md) e [Nozioni di base sull’importazione in streaming da origini Apache Kafka](materialized-view-streaming-ingestion-getting-started-MSK.md). | Prendilo in considerazione per i casi d’uso in cui i dati vengono prima trasmessi in streaming in file in Amazon S3 e poi caricati da Amazon S3. Se non è necessario conservare i dati in Amazon S3, spesso puoi prendere in considerazione lo streaming dei dati direttamente in Amazon Redshift. |
| Esecuzione di query sui data lake | Esecuzione di query direttamente da una tabella di data lake anziché importazione dei contenuti della tabella in una tabella locale. Per ulteriori informazioni, consulta [Amazon Redshift Spectrum](c-using-spectrum.md). | Utilizzalo quando il caso d’uso non richiede le prestazioni delle query su tabelle locali in Amazon Redshift. |
| Caricamento in batch con Amazon Redshift Query Editor V2 | Puoi preparare ed eseguire i carichi di lavoro di importazione di file in batch in modo visivo in Amazon Redshift Query Editor V2. Per ulteriori informazioni, consulta [Caricamento di dati da Amazon S3](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data) nella *Guida alla gestione di Amazon Redshift*. | Utilizzalo quando desideri che Query Editor V2 prepari le istruzioni COPY e desideri uno strumento visivo per semplificare il processo di preparazione delle istruzioni COPY. |
| Caricare i dati da un file locale tramite Amazon Redshift Query Editor V2 | Puoi caricare i file direttamente dal desktop nelle tabelle Amazon Redshift senza dover caricare manualmente i file in Amazon S3. Per ulteriori informazioni, consulta [Caricamento di dati da una configurazione di file e da un flusso di lavoro locali](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data-local) nella *Guida alla gestione di Amazon Redshift*. | Utilizzalo quando hai bisogno di caricare rapidamente i file dal computer locale per eseguire query una tantum. Con questo metodo, Amazon Redshift Query Editor v2 archivia temporaneamente il file in un bucket Amazon S3 di proprietà del cliente ed esegue un comando di copia utilizzando questo percorso di Amazon S3. |
Il modo più efficiente per caricare una tabella è il comando COPY. Inoltre, è possibile aggiungere dati alle tabelle usando i comandi INSERT, sebbene sia molto meno efficiente rispetto all'utilizzo di COPY. Il comando COPY è in grado di leggere da più file di dati o più flussi di dati contemporaneamente. Amazon Redshift assegna il carico di lavoro ai nodi Amazon Redshift ed esegue le operazioni di caricamento in parallelo, tra cui l’ordinamento delle righe e la distribuzione dei dati tra le sezioni dei nodi.
**Nota**
Le tabelle esterne di Amazon Redshift Spectrum sono di sola lettura. Non puoi utilizzare COPY o INSERT in una tabella esterna.
Per accedere ai dati su altre AWS risorse, Amazon Redshift deve disporre dell'autorizzazione ad accedere a tali risorse e a eseguire le azioni necessarie per accedere ai dati. Puoi usare AWS Identity and Access Management (IAM) per limitare l'accesso degli utenti alle risorse e ai dati di Amazon Redshift.
Dopo il caricamento iniziale dei dati, se aggiungi, modifichi o elimini una grande quantità di dati, devi eseguire il follow-up tramite un comando VACUUM per riorganizzare i dati e recuperare spazio dopo le eliminazioni. Devi anche eseguire un comando ANALYZE per aggiornare le statistiche della tabella.
**Topics**
+ [Caricamento delle tabelle con il comando COPY](t_Loading_tables_with_the_COPY_command.md)
+ [Creare un’integrazione di eventi S3 per copiare automaticamente i file dai bucket Amazon S3](loading-data-copy-job.md)
+ [Caricamento di tabelle con comandi DML](t_Updating_tables_with_DML_commands.md)
+ [Esecuzione di una copia completa](performing-a-deep-copy.md)
+ [Analisi delle tabelle](t_Analyzing_tables.md)
+ [Vacuum delle tabelle](t_Reclaiming_storage_space202.md)
+ [Gestione delle operazioni di scrittura simultanee](c_Concurrent_writes.md)
+ [Tutorial: Caricamento dei dati da Amazon S3](tutorial-loading-data.md)
# Caricamento delle tabelle con il comando COPY
Il comando COPY sfrutta l'architettura MPP (Massively Parallel Processing) di Amazon Redshift per leggere e caricare dati in parallelo da file su Amazon S3, da una tabella DynamoDB o da output di testo da uno o più host remoti.
Prima di imparare tutte le opzioni del comando COPY, consigliamo di apprendere le opzioni di base per caricare i dati di Amazon S3. Nell *Guida alle operazioni di base di Amazon Redshift* viene illustrato il semplice utilizzo del comando COPY per caricare i dati di Amazon S3 con un ruolo IAM predefinito. Per i dettagli, consulta [Fase 4: caricare i dati da Amazon S3 in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html).
**Nota**
Consigliamo l'uso del comando COPY per caricare grandi quantità di dati. L'utilizzo di singole istruzioni INSERT per popolare una tabella potrebbe essere eccessivamente lento. In alternativa, se i dati sono già presenti in altre tabelle di database Amazon Redshift, utilizzare INSERT INTO... SELECT o CREATE TABLE AS per migliorare le prestazioni. Per informazioni, consulta [INSERT](r_INSERT_30.md) or [CREATE TABLE AS](r_CREATE_TABLE_AS.md).
Per caricare dati da un'altra AWS risorsa, Amazon Redshift deve disporre dell'autorizzazione per accedere alla risorsa ed eseguire le azioni necessarie.
Per concedere o revocare il privilegio per caricare dati in una tabella utilizzando un comando COPY, concedi o revoca il privilegio INSERT.
I dati devono essere nel formato corretto per il caricamento nella tabella Amazon Redshift. Questa sezione presenta le linee guida per preparare e verificare i dati prima del caricamento e per convalidare un'istruzione COPY prima di eseguirla.
Per proteggere le informazioni nei file, è possibile eseguire la crittografia dei file di dati prima di caricarli nel bucket Amazon S3; COPY eseguirà la decrittografia dei dati mentre esegue il caricamento. Inoltre, è possibile limitare l'accesso ai dati del caricamento fornendo credenziali di sicurezza temporanee agli utenti. Le credenziali di sicurezza temporanee offrono maggiore sicurezza perché hanno una durata breve e non possono essere riutilizzate dopo la loro scadenza.
Amazon Redshift dispone di funzionalità integrate per COPY per caricare rapidamente dati non compressi e delimitati. È possibile comprimere i file tramite gzip, lzop o bzip2 per risparmiare tempo nel caricamento dei file.
Se nella query COPY si trovano le seguenti parole chiave, la suddivisione automatica dei dati non compressi non è supportata: ESCAPE, REMOVEQUOTES e FIXEDWIDTH. Ma la parola chiave CSV è supportata.
Per garantire la sicurezza dei dati in transito all'interno del AWS cloud, Amazon Redshift utilizza SSL con accelerazione hardware per comunicare con Amazon S3 o Amazon DynamoDB per le operazioni di COPY, UNLOAD, backup e ripristino.
Quando si carica la tabella direttamente da una tabella di Amazon DynamoDB, si ha la possibilità di controllare la quantità di throughput assegnato di Amazon DynamoDB che viene utilizzato.
Facoltativamente, è possibile consentire a COPY di analizzare i dati di input e applicare automaticamente codifiche di compressione ottimali alla tabella come parte del processo di caricamento.
**Topics**
+ [Credenziali e autorizzazioni di accesso](loading-data-access-permissions.md)
+ [Preparazione dei dati di input](t_preparing-input-data.md)
+ [Caricamento di dati da Amazon S3](t_Loading-data-from-S3.md)
+ [Caricamento di dati da Amazon EMR](loading-data-from-emr.md)
+ [Caricamento di dati da host remoti](loading-data-from-remote-hosts.md)
+ [Caricamento di dati da una tabella Amazon DynamoDB](t_Loading-data-from-dynamodb.md)
+ [Verifica del caricamento corretto dei dati](verifying-that-data-loaded-correctly.md)
+ [Convalida dei dati di input](t_Validating_input_files.md)
+ [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md)
+ [Ottimizzazione dello storage per tabelle limitate](c_load_compression_hidden_cols.md)
+ [Caricamento dei valori delle colonne predefiniti](c_loading_default_values.md)
+ [Risoluzione di problemi di caricamento dei dati](t_Troubleshooting_load_errors.md)
# Credenziali e autorizzazioni di accesso
Per caricare o scaricare dati utilizzando un'altra AWS risorsa, come Amazon S3, Amazon DynamoDB, Amazon EMR o Amazon EC2, Amazon Redshift deve disporre dell'autorizzazione per accedere alla risorsa ed eseguire le azioni necessarie per accedere ai dati. Ad esempio, per caricare i dati da Amazon S3, COPY deve avere accesso LIST al bucket e accesso GET per gli oggetti del bucket.
Per ottenere l’autorizzazione ad accedere a una risorsa, Amazon Redshift deve essere autenticato. È possibile scegliere il controllo degli accessi basato su ruoli o il controllo degli accessi basato su chiave. Questa sezione presenterà una panoramica dei due metodi. Per esempi e dettagli completi, consultare [AWS Autorizzazioni per accedere ad altre risorse](copy-usage_notes-access-permissions.md).
## Controllo degli accessi basato sui ruoli
Con il controllo degli accessi basato su ruoli, Amazon Redshift assume in modo temporaneo e automatico un ruolo AWS Identity and Access Management (IAM). Quindi, in base alle autorizzazioni concesse al ruolo, Amazon Redshift può accedere alle AWS risorse richieste.
Ti consigliamo di utilizzare il controllo degli accessi basato sui ruoli perché fornisce un controllo più sicuro e dettagliato dell'accesso alle AWS risorse e ai dati sensibili degli utenti, oltre a salvaguardare le tue credenziali. AWS
Per utilizzare il controllo degli accessi basato su ruoli, devi dapprima creare un ruolo IAM utilizzando il tipo di ruolo di servizio Amazon Redshift, quindi collegare il ruolo al data warehouse. Il ruolo deve avere, come minimo, le autorizzazioni elencate in [Autorizzazioni IAM per COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Per i passaggi per creare un ruolo IAM e collegarlo al cluster, consulta [Creazione di un ruolo IAM per consentire al cluster Amazon Redshift di accedere ai AWS servizi](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html#authorizing-redshift-service-creating-an-iam-role) nella Guida alla gestione di *Amazon Redshift*.
È possibile aggiungere un ruolo a un cluster o visualizzare i ruoli associati a un cluster utilizzando la Console di gestione, la CLI o l'API di Amazon Redshift. Per ulteriori informazioni, consulta [Autorizzazione delle operazioni COPY e UNLOAD mediante ruoli IAM](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role.html) nella *Guida alla gestione di Amazon Redshift*.
Quando crei un ruolo IAM, IAM restituisce un Amazon Resource Name (ARN) per il ruolo. Per eseguire il comando COPY tramite il ruolo IAM, fornisci l'ARN del ruolo tramite il parametro IAM\$1ROLE o il parametro CREDENTIALS.
Il seguente esempio di comando COPY utilizza il parametro IAM\$1ROLE con il ruolo `MyRedshiftRole` per l'autenticazione.
```
COPY customer FROM 's3://amzn-s3-demo-bucket/mydata'
IAM_ROLE 'arn:aws:iam::12345678901:role/MyRedshiftRole';
```
L' AWS utente deve disporre almeno delle autorizzazioni elencate in. [Autorizzazioni IAM per COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions)
## Controllo degli accessi basato su chiave
Con il controllo degli accessi basato su chiavi, fornisci l'ID della chiave di accesso e la chiave di accesso segreta per un utente autorizzato ad accedere alle AWS risorse che contengono i dati.
**Nota**
Consigliamo vivamente di utilizzare un ruolo IAM per l'autenticazione invece di fornire un ID chiave di accesso in chiaro e una chiave di accesso segreta. Se scegli il controllo degli accessi basato su chiavi, non utilizzare mai le credenziali del tuo AWS account (root). Creare sempre un utente IAM e fornire l'ID della chiave di accesso e la chiave di accesso segreta di quell'utente. Per la procedura per creare un utente IAM, consultare [Creazione di un utente IAM nell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html).
# Preparazione dei dati di input
Se i dati di input non sono compatibili con le colonne della tabella che li riceveranno, il comando COPY fallirà.
Attieniti alle seguenti linee guida per garantire che i dati di input siano validi:
+ I dati possono contenere solo fino a quattro byte di caratteri con codice UTF-8.
+ Verifica che le stringhe CHAR e VARCHAR non siano più lunghe delle colonne corrispondenti. Le stringhe VARCHAR sono misurate in byte, non in caratteri, quindi, ad esempio, una stringa di quattro caratteri di caratteri cinesi che occupano quattro byte ciascuno richiede una colonna VARCHAR(16).
+ I caratteri multibyte possono essere utilizzati solo con colonne VARCHAR. Verifica che i caratteri multibyte non siano più lunghi di quattro byte.
+ Verifica che i dati per le colonne CHAR contengano solo caratteri a byte singolo.
+ Non includere caratteri speciali o sintassi per indicare l'ultimo campo in un record. Questo campo può essere un delimitatore.
+ Se i dati includono terminatori null, indicati anche come NUL (UTF-8 0000) o zero binario (0x000), è possibile caricare questi caratteri come NULLS nelle colonne CHAR o VARCHAR tramite l'opzione NULL AS nel comando COPY: `null as '\0'` o `null as '\000'` . Se non utilizzi NULL AS, i terminatori null causeranno il fallimento del COPY.
+ Se le stringhe contengono caratteri speciali, come delimitatori e nuove righe incorporate, utilizza l'opzione ESCAPE con il comando [COPY](r_COPY.md).
+ Verificare che tutte le virgolette singole e doppie siano abbinate correttamente.
+ Verifica che le stringhe a virgola mobile siano in formato a virgola mobile standard, ad esempio 12.123 o in formato esponenziale, ad esempio 1.0E4.
+ Verifica che tutte le stringhe timestamp e data seguano le specifiche per [Stringhe DATEFORMAT e TIMEFORMATEsempio](r_DATEFORMAT_and_TIMEFORMAT_strings.md). Il formato di timestamp predefinito è YYYY-MM-DD hh:mm:ss e il formato di data predefinito è. YYYY-MM-DD
+ Per ulteriori informazioni sui confini e sulle limitazioni sui singoli tipi di dati, consultare [Tipi di dati](c_Supported_data_types.md). Per informazioni sugli errori di carattere multibyte, consultare [Errori di caricamento di caratteri multibyte](multi-byte-character-load-errors.md)
# Caricamento di dati da Amazon S3
Il comando COPY sfrutta l'architettura MPP (Massively Parallel Processing) di Amazon Redshift per leggere e caricare dati in parallelo da uno o più file in un bucket Amazon S3. È possibile ottenere il massimo dall'elaborazione parallela suddividendo i dati in più file, nei casi in cui i file sono compressi. Ci sono eccezioni a questa regola. Queste sono descritte in dettaglio in [Caricamento dei file di dati](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-use-multiple-files.html). È anche possibile ottenere il massimo dall'elaborazione parallela impostando le chiavi di distribuzione nelle tabelle. Per ulteriori informazioni sulle chiavi di distribuzione, consulta [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md).
I dati vengono caricati nella tabella di destinazione, una riga per riga. I campi nel file di dati corrispondono alle colonne della tabella in ordine, da sinistra a destra. I campi nei file di dati possono essere a larghezza fissa o delimitati da caratteri; il delimitatore predefinito è una barra verticale (\$1). Per impostazione predefinita, vengono caricate tutte le colonne della tabella, ma è possibile definire facoltativamente un elenco di colonne separato da virgole. Se una colonna della tabella non è inclusa nell'elenco delle colonne specificato nel comando COPY, viene caricata con un valore predefinito. Per ulteriori informazioni, consulta [Caricamento dei valori delle colonne predefiniti](c_loading_default_values.md).
**Topics**
+ [Caricamento dei dati da file compressi e non compressi](t_splitting-data-files.md)
+ [Caricamento di file in Amazon S3 da usare con COPY](t_uploading-data-to-S3.md)
+ [Utilizzo del comando COPY per il caricamento da Amazon S3](t_loading-tables-from-s3.md)
# Caricamento dei dati da file compressi e non compressi
Quando carichi dati compressi, ti consigliamo di suddividere i dati per ogni tabella in più file. Quando carichi dati non compressi e delimitati, il comando COPY utilizza l'elaborazione massivamente parallela (MPP) e gli intervalli di scansione per caricare dati da file di grandi dimensioni in un bucket Amazon S3.
## Caricamento dei dati da più file compressi
Nei casi in cui sono stati compressi dati, ti consigliamo di suddividerli per ogni tabella in più file. Il comando COPY può caricare dati da più file in parallelo. È possibile caricare più file specificando un prefisso comune o *chiave di prefisso*, per l'insieme o elencando in modo esplicito i file in un file manifest.
Dividi i dati in file in modo che il numero di file sia un multiplo del numero di sezioni nel cluster. In questo modo Amazon Redshift può dividere i dati in modo uniforme tra le sezioni. Il numero di sezioni per nodo dipende dalla dimensione dei nodi del cluster. Ad esempio, ogni nodo di calcolo dc2.large dispone di due sezioni e ogni nodo di calcolo dc2.8xlarge dispone di 16 sezioni. Per ulteriori informazioni sul numero di sezioni per ogni dimensione di nodo, consulta [Informazioni su cluster e nodi](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) nella *Guida alla gestione di Amazon Redshift*.
Tutti i nodi partecipano all'esecuzione di query parallele, lavorando sui dati di calcolo distribuiti più uniformemente possibile all'interno delle sezioni. Se disponi di un cluster con due nodi dc2.large, puoi suddividere i dati in quattro file o in multipli di quattro. Amazon Redshift non prende in considerazione la dimensione di file nella suddivisione del carico di lavoro. Pertanto, è necessario assicurarsi che i file abbiano approssimativamente le stesse dimensioni, da 1 MB a 1 GB dopo la compressione.
Per utilizzare i prefissi degli oggetti per identificare i file di caricamento, denomina ciascun file con un prefisso comune. Ad esempio, il file `venue.txt` può essere diviso in quattro file, come segue.
```
venue.txt.1
venue.txt.2
venue.txt.3
venue.txt.4
```
Se collochi più file in una cartella nel bucket, specificando il nome della cartella come prefisso, COPY carica tutti i file nella cartella. Se elenchi in modo esplicito i file da caricare tramite un file manifest, i file possono risiedere in diversi bucket o diverse cartelle.
Per ulteriori informazioni sui file manifest, consulta [Utilizzo di un manifest per specificare i fili di dati](r_COPY_command_examples.md#copy-command-examples-manifest).
## Caricamento di dati da file delimitati e non compressi
Quando carichi dati delimitati e non compressi, il comando COPY utilizza l'architettura MPP (Massively Parallel Processing) di Amazon Redshift. Amazon Redshift utilizza automaticamente le sezioni che lavorano in parallelo per caricare intervalli di dati da un file di grandi dimensioni in un bucket Amazon S3. Il file deve essere delimitato per il caricamento parallelo. Ad esempio, tubo delimitato. Il caricamento automatico dei dati in parallelo con il comando COPY non è disponibile per i file CSV. È possibile utilizzare l'elaborazione parallela impostando le chiavi di distribuzione nelle tabelle. Per ulteriori informazioni sulle chiavi di distribuzione, consulta [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md).
Il caricamento automatico dei dati in parallelo non è supportato se la query COPY include una delle parole chiave ESCAPE, REMOVEQUOTES e FIXEDWIDTH.
I dati dai file vengono caricati nella tabella di destinazione, una riga per riga. I campi nel file di dati corrispondono alle colonne della tabella in ordine, da sinistra a destra. I campi nei file di dati possono essere a larghezza fissa o delimitati da caratteri; il delimitatore predefinito è una barra verticale (\$1). Per impostazione predefinita, vengono caricate tutte le colonne della tabella, ma è possibile definire facoltativamente un elenco di colonne separato da virgole. Se una colonna della tabella non è inclusa nell'elenco delle colonne specificato nel comando COPY, viene caricata con un valore predefinito. Per ulteriori informazioni, consulta [Caricamento dei valori delle colonne predefiniti](c_loading_default_values.md).
Segui questo procedimento generale per caricare dati da Amazon S3, quando i dati non sono compressi e delimitati:
1. Caricare i file su Amazon S3.
1. Esegui un comando COPY per caricare la tabella.
1. Verifica i dati siano stati caricati correttamente.
Per esempi di comandi COPY, consultare [Esempi di COPY](r_COPY_command_examples.md). Per informazioni sui dati caricati in Amazon Redshift, consultare le tabelle di sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) e [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md).
Per ulteriori informazioni sui nodi e sulle sezioni contenute in ciascun nodo, consulta [Informazioni su cluster e nodi](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) nella *Guida alla gestione di Amazon Redshift*.
# Caricamento di file in Amazon S3 da usare con COPY
Ci sono un paio di approcci da adottare quando si caricano file di testo su Amazon S3:
+ Se disponi di file compressi, ti consigliamo di dividere file di grandi dimensioni per beneficiare dall'elaborazione parallela in Amazon Redshift.
+ D'altra parte, COPY divide automaticamente dati di file di grandi dimensioni, non compressi e delimitati da testo per facilitare il parallelismo e distribuire efficacemente i dati da file di grandi dimensioni.
Creare un bucket Amazon S3 per contenere i file di dati, quindi caricare i file di dati nel bucket. Per informazioni sulla creazione di bucket e sul caricamento di file, consultare [Utilizzo dei bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) nella *Guida per l'utente di Amazon Simple Storage Service.*
**Importante**
Il bucket Amazon S3 che contiene i file di dati deve essere creato nella stessa regione AWS del cluster a meno che non si utilizzi l'opzione [REGION](copy-parameters-data-source-s3.md#copy-region) per specificare la regione in cui si trova il bucket Amazon S3.
Assicurati che gli intervalli IP S3 siano aggiunti all'elenco di indirizzi consentiti. Per ulteriori informazioni sugli intervalli IP S3 richiesti, consulta [Isolamento di rete](https://docs.aws.amazon.com//redshift/latest/mgmt/security-network-isolation.html#network-isolation).
È possibile creare un bucket Amazon S3 in una regione specifica selezionando la regione quando si crea il bucket con la console Amazon S3 oppure specificando un endpoint quando si crea il bucket con la CLI o l'API di Amazon S3.
In seguito al caricamento dei dati, verificare che in Amazon S3 siano presenti i file corretti.
**Topics**
+ [Gestione della coerenza dei dati](managing-data-consistency.md)
+ [Caricamento di dati crittografati su Amazon S3](t_uploading-encrypted-data.md)
+ [Verifica della presenza dei file corretti nel bucket](verifying-that-correct-files-are-present.md)
# Gestione della coerenza dei dati
Amazon S3 offre una forte read-after-write coerenza per le operazioni COPY, UNLOAD, INSERT (tabella esterna), CREATE EXTERNAL TABLE AS e Amazon Redshift Spectrum sui bucket Amazon S3 in tutte le regioni. AWS Inoltre, le operazioni di lettura su Amazon S3 Select, gli elenchi di controllo accessi (ACL) di Amazon S3, i tag oggetto Amazon S3 e i metadati degli oggetti (ad esempio oggetto HEAD) sono fortemente consistenti. Per informazioni più dettagliate sulla coerenza dei dati, consultare [Modello di consistenza dei dati di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Introduction.html#ConsistencyModel) nella *Guida per l'utente di Amazon Simple Storage Service*.
# Caricamento di dati crittografati su Amazon S3
Amazon S3 supporta sia la crittografia lato server sia la crittografia lato client. In questo argomento vengono discusse le differenze tra la crittografia lato server e quella lato client e vengono descritte le fasi per utilizzare la crittografia lato client con Amazon Redshift. La crittografia lato server è trasparente per Amazon Redshift.
## Crittografia lato server
La crittografia lato server è una crittografia dei dati a riposo, vale a dire che Amazon S3 consente di crittografare i dati durante il caricamento e ne esegue la decrittografia quando avviene l'accesso. Quando si esegue il caricamento delle tabelle utilizzando un comando COPY, non esiste differenza nel modo in cui si esegue il caricamento da oggetti non crittografati o crittografati lato server in Amazon S3. Per ulteriori informazioni sulla crittografia lato server, consultare [Utilizzo della crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
## Crittografia lato client
Nella crittografia lato client, l'applicazione client gestisce la crittografia dei dati, le chiavi di crittografia e gli strumenti correlati. È possibile caricare i dati in un bucket Amazon S3 utilizzando la crittografia lato client, quindi caricare i dati utilizzando il comando COPY con l'opzione ENCRYPTED e una chiave di crittografia privata per fornire maggiore sicurezza.
Crittografi i dati utilizzando la crittografia envelope. Con la *crittografia envelope,* l'applicazione gestisce tutta la crittografia in modo esclusivo. Le tue chiavi di crittografia private e i tuoi dati non crittografati non vengono mai inviati a AWS, quindi è molto importante gestire in modo sicuro le chiavi di crittografia. Se perdi le chiavi di crittografia, non sarai in grado di decrittografare i dati e non potrai recuperarle da. AWS La crittografia envelope combina le prestazioni della crittografia simmetrica rapida, mantenendo al contempo la maggiore sicurezza fornita dalla gestione delle chiavi con chiavi asimmetriche. Una chiave one-time-use simmetrica (la chiave simmetrica dell'involucro) viene generata dal client di crittografia Amazon S3 per crittografare i dati, quindi tale chiave viene crittografata dalla chiave principale e archiviata insieme ai dati in Amazon S3. Quando Amazon Redshift accede ai dati durante un caricamento, la chiave simmetrica crittografata viene recuperata e decrittografata con la chiave reale, quindi i dati vengono decrittografati.
Per lavorare con i dati crittografati lato client di Amazon S3 in Amazon Redshift, seguire la procedura descritta in [Protezione dei dati con la crittografia lato client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) nella *Guida per l'utente di Amazon Simple Storage Service*, con i requisiti aggiuntivi utilizzati:
+ **Crittografia simmetrica**: la classe di AWS SDK per Java `AmazonS3EncryptionClient` utilizza la crittografia envelope, descritta in precedenza, che si basa sulla crittografia della chiave simmetrica. Utilizzare questa classe per creare un client Amazon S3 per caricare dati crittografati lato client.
+ **Una chiave simmetrica root AES a 256 bit**: una chiave root crittografa la chiave envelope. Trasferisci la chiave root all'istanza della chiave `AmazonS3EncryptionClient`. Salvare questa chiave, perché sarà necessaria per copiare i dati in Amazon Redshift.
+ **Metadati oggetto per archiviare la chiave envelope crittografata**: per impostazione predefinita, Amazon S3 archivia la chiave envelope come metadati degli oggetti per la classe `AmazonS3EncryptionClient`. La chiave envelope crittografata che viene archiviata come metadati degli oggetti viene utilizzata durante il processo di decrittografia.
**Nota**
Se si ottiene un messaggio indicante un errore di crittografia quando si usa l'API di crittografia per la prima volta, la propria versione del JDK potrebbe avere un file di policy per l'ambito di Java Cryptography Extension (JCE) che limita la lunghezza massima della chiave per le trasformazioni di crittografia e decrittografia a 128 bit. Per informazioni su come risolvere questo problema, consulta [Specificare la crittografia lato client utilizzando l'SDK for AWS Java nella Guida per l'](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryptionUpload.html)utente di *Amazon Simple Storage Service*.
Per informazioni sul caricamento di file crittografati lato client nelle tabelle Amazon Redshift con il comando COPY, consultare [Caricamento di file di dati crittografati da Amazon S3](c_loading-encrypted-files.md).
## Esempio: caricamento di dati crittografati lato client
Per un esempio di come utilizzare l' AWS SDK for Java per caricare dati crittografati lato client, consulta [Protezione dei dati utilizzando la crittografia lato client nella Guida per](https://docs.aws.amazon.com/AmazonS3/latest/userguide/encrypt-client-side-symmetric-master-key.html) l'utente di *Amazon Simple Storage Service*.
La seconda opzione illustra le scelte da effettuare durante la crittografia lato client in modo che i dati possano essere caricati in Amazon Redshift. Nello specifico, l'esempio illustra l'uso dei metadati degli oggetti per archiviare la chiave envelope crittografata e l'uso di una chiave simmetrica root AES a 256 bit.
Questo esempio fornisce un codice di esempio che utilizza l' AWS SDK for Java per creare una chiave radice simmetrica AES a 256 bit e salvarla in un file. Successivamente, nell'esempio viene caricato un oggetto in Amazon S3 utilizzando un client di crittografia S3 che prima crittografa i dati di esempio sul lato client. Nell'esempio si scarica anche l'oggetto e si verifica che i dati corrispondano.
# Verifica della presenza dei file corretti nel bucket
Dopo aver caricato i file nel bucket Amazon S3, consigliamo di elencare i contenuti del bucket per verificare che siano presenti tutti i file corretti e che non siano presenti file indesiderati. Ad esempio, se il bucket `amzn-s3-demo-bucket` conserva un file denominato `venue.txt.back`, quel file verrà caricato, forse involontariamente, dal seguente comando:
```
COPY venue FROM 's3://amzn-s3-demo-bucket/venue' … ;
```
Se desideri controllare specificamente quali file sono caricati, è possibile utilizzare un file manifest per elencare in modo esplicito i file di dati. Per ulteriori informazioni sull'utilizzo di un file manifest, consultare l'[copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file)opzione per il comando COPY e [Utilizzo di un manifest per specificare i fili di dati](r_COPY_command_examples.md#copy-command-examples-manifest) negli esempi COPY.
Per ulteriori informazioni sull'elenco dei contenuti del bucket, consultare [Elenco delle chiavi degli oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ListingKeysUsingAPIs.html) nella *Guida per gli sviluppatori di Amazon S3*.
# Utilizzo del comando COPY per il caricamento da Amazon S3
Utilizzare il comando [COPY](r_COPY.md) per caricare una tabella in parallelo dai file di dati in Amazon S3. È possibile specificare i file da caricare tramite il prefisso di un oggetto Amazon S3 o un file manifest.
La sintassi per specificare un file caricare tramite un prefisso è la seguente.
```
COPY FROM 's3:///'
authorization;
```
Il file manifest è un file in formato JSON che elenca i file di dati da caricare. La sintassi per specificare un file caricare tramite un file manifest è la seguente.
```
COPY FROM 's3:///'
authorization
MANIFEST;
```
La tabella da caricare deve esistere già nel database. Per ulteriori informazioni sulla creazione di una tabella, consultare [CREATE TABLE](r_CREATE_TABLE_NEW.md) nel riferimento SQL.
I valori per *l'autorizzazione* forniscono l' AWS autorizzazione necessaria ad Amazon Redshift per accedere agli oggetti Amazon S3. Per informazioni sulle autorizzazioni richieste, consultare [Autorizzazioni IAM per COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Il metodo preferito per l'autenticazione è specificare il parametro IAM\$1ROLE e fornire l'Amazon Resource Name (ARN) per un ruolo IAM con le autorizzazioni necessarie. Per ulteriori informazioni, consulta [Controllo degli accessi basato sui ruoli](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based).
Per eseguire l'autenticazione utilizzando il parametro IAM\$1ROLE, sostituiscilo con ** e ** come mostrato nella sintassi seguente.
```
IAM_ROLE 'arn:aws:iam:::role/'
```
L'esempio seguente mostra l'autenticazione utilizzando un ruolo IAM.
```
COPY customer
FROM 's3://amzn-s3-demo-bucket/mydata'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
```
Per ulteriori informazioni su altre opzioni di autorizzazione, consulta [Parametri di autorizzazione](copy-parameters-authorization.md)
Se desideri convalidare i dati senza caricare effettivamente la tabella, utilizza l'opzione NOLOAD con il comando [COPY](r_COPY.md).
L'esempio seguente mostra le prime righe di dati delimitati da barra verticale in un file denominato `venue.txt`.
```
1|Toyota Park|Bridgeview|IL|0
2|Columbus Crew Stadium|Columbus|OH|0
3|RFK Stadium|Washington|DC|0
```
Prima di caricare il file in Amazon S3, dividere il file in più file in modo che il comando COPY possa caricarlo utilizzando l'elaborazione parallela. Il numero di file deve essere un multiplo del numero di sezioni nel cluster. Suddividi i file di dati di caricamento di modo che siano all'incirca della stessa dimensione, tra 1 MB e 1 GB dopo la compressione. Per ulteriori informazioni, consulta [Caricamento dei dati da file compressi e non compressi](t_splitting-data-files.md).
Ad esempio, il file `venue.txt` può essere diviso in quattro file, come segue:
```
venue.txt.1
venue.txt.2
venue.txt.3
venue.txt.4
```
Il comando seguente COPY carica la tabella VENUE utilizzando i dati delimitati da barra verticale nei file di dati con il prefisso “venue” nel bucket Amazon S3 `amzn-s3-demo-bucket`.
**Nota**
Il bucket Amazon S3 `amzn-s3-demo-bucket` nei seguenti esempi non esiste. Per i comandi COPY di esempio che utilizzano dati reali in un bucket Amazon S3 esistente, consultare [Caricamento dei dati di esempio](https://docs.aws.amazon.com/redshift/latest/gsg/cm-dev-t-load-sample-data.html).
```
COPY venue FROM 's3://amzn-s3-demo-bucket/venue'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
DELIMITER '|';
```
Se non esiste alcun oggetto Amazon S3 con prefisso della chiave 'venue', il caricamento non riesce.
**Topics**
+ [Utilizzo di un manifest per specificare i fili di dati](loading-data-files-using-manifest.md)
+ [Caricamento di file di dati compressi da Amazon S3](t_loading-gzip-compressed-data-files-from-S3.md)
+ [Caricamento di dati a larghezza fissa da Amazon S3](t_loading_fixed_width_data.md)
+ [Caricamento di dati multibyte da Amazon S3](t_loading_unicode_data.md)
+ [Caricamento di file di dati crittografati da Amazon S3](c_loading-encrypted-files.md)
# Utilizzo di un manifest per specificare i fili di dati
Puoi utilizzare un manifesto per assicurare che per un caricamento di dati il comando COPY carichi tutti i file richiesti e solo quelli. È possibile utilizzare un manifest per caricare file da diversi bucket o file che non condividono lo stesso prefisso. Anziché fornire il percorso di un oggetto per il comando COPY, fornisci il nome per un file di testo in formato JSON che elenca in modo esplicito i file da caricare. L'URL nel manifest deve specificare il nome bucket e il percorso completo dell'oggetto per il file, non solo un prefisso.
Per ulteriori informazioni sui file manifest, consultare l'esempio di comando COPY [Utilizzo di un manifest per specificare i file di dati](r_COPY_command_examples.md#copy-command-examples-manifest).
L'esempio seguente mostra il JSON per il caricamento dei file da diversi bucket e con nomi di file che iniziano con stamp di data.
```
{
"entries": [
{"url":"s3://amzn-s3-demo-bucket1/2013-10-04-custdata", "mandatory":true},
{"url":"s3://amzn-s3-demo-bucket1/2013-10-05-custdata", "mandatory":true},
{"url":"s3://amzn-s3-demo-bucket2/2013-10-04-custdata", "mandatory":true},
{"url":"s3://amzn-s3-demo-bucket2/2013-10-05-custdata", "mandatory":true}
]
}
```
Il flag `mandatory` facoltativo specifica se COPY deve restituire un errore qualora il file non venga trovato. Il valore predefinito di `mandatory` è `false`. Indipendentemente da eventuali impostazioni obbligatorie, COPY terminerà se non vengono trovati file.
L'esempio seguente esegue il comando COPY con manifest nell'esempio precedente, che viene denominato `cust.manifest`.
```
COPY customer
FROM 's3://amzn-s3-demo-bucket/cust.manifest'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
MANIFEST;
```
## Utilizzo di un manifest creato da UNLOAD
Un manifest creato da un'operazione [UNLOAD](r_UNLOAD.md) utilizzando il parametro MANIFEST potrebbe avere chiavi non richieste per l'operazione di COPY. Ad esempio, il manifest `UNLOAD` seguente include una chiave `meta` necessaria per una tabella esterna di Amazon Redshift Spectrum e per il caricamento di file di dati in formato `ORC` o `Parquet`. La chiave `meta` contiene una chiave `content_length` con un valore che rappresenta le dimensioni effettive del file in byte. L'operazione di COPY richiede solo la chiave `url` e una chiave opzionale `mandatory`.
```
{
"entries": [
{"url":"s3://amzn-s3-demo-bucket/unload/manifest_0000_part_00", "meta": { "content_length": 5956875 }},
{"url":"s3://amzn-s3-demo-bucket/unload/unload/manifest_0001_part_00", "meta": { "content_length": 5997091 }}
]
}
```
Per ulteriori informazioni sui file manifest, consulta [Utilizzo di un manifest per specificare i fili di dati](r_COPY_command_examples.md#copy-command-examples-manifest).
# Caricamento di file di dati compressi da Amazon S3
Per caricare file di dati compressi utilizzando gzip, lzop o bzip2, includete l'opzione corrispondente: GZIP, LZOP o. BZIP2
Ad esempio, il seguente comando carica da file compressi utilizzando lzop.
```
COPY customer FROM 's3://amzn-s3-demo-bucket/customer.lzo'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
DELIMITER '|' LZOP;
```
**Nota**
Se comprimi un file di dati con la compressione lzop e usi l’opzione *--filter*, il comando COPY non la supporta.
# Caricamento di dati a larghezza fissa da Amazon S3
I file di dati a larghezza fissa hanno lunghezze uniformi per ciascuna colonna di dati. Ogni campo in un file di dati a larghezza fissa ha esattamente la stessa lunghezza e la stessa posizione. Per i dati di carattere (CHAR e VARCHAR) in un file di dati a larghezza fissa, è necessario includere spazi iniziali o finali come segnaposti per mantenere uniforme la larghezza. Per gli interi, è necessario utilizzare gli zero iniziali come segnaposti. Un file di dati a larghezza fissa non ha delimitatori per separare le colonne.
Per caricare un file di dati a larghezza fissa in una tabella esistente, UTILIZZA il parametro FIXEDWIDTH nel comando COPY. Le specifiche della tabella devono corrispondere al valore di fixedwidth\$1spec affinché i dati vengano caricati correttamente.
Per caricare dati a larghezza fissa da un file a una tabella, emetti il seguente comando:
```
COPY table_name FROM 's3://amzn-s3-demo-bucket/prefix'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
FIXEDWIDTH 'fixedwidth_spec';
```
Il parametro *fixedwidth\$1spec* è una stringa che contiene un identificatore per ogni colonna e la larghezza di ogni colonna, separati da due punti. Le coppie **column:width** sono delimitate da virgole. L'identificatore può essere qualsiasi elemento desiderato: numeri, lettere o una combinazione dei due. L'identificatore non ha alcuna relazione con la tabella stessa, quindi la specifica deve contenere le colonne nello stesso ordine della tabella.
I seguenti due esempi mostrano la stessa specifica, il primo con identificatori numerici e il secondo con identificatori di stringa:
```
'0:3,1:25,2:12,3:2,4:6'
```
```
'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6'
```
Il seguente esempio mostra dati di esempio a larghezza fissa che potrebbero essere caricati nella tabella VENUE utilizzando le specifiche precedenti:
```
1 Toyota Park Bridgeview IL0
2 Columbus Crew Stadium Columbus OH0
3 RFK Stadium Washington DC0
4 CommunityAmerica Ballpark Kansas City KS0
5 Gillette Stadium Foxborough MA68756
```
Il seguente comando COPY carica questo set di dati nella tabella VENUE:
```
COPY venue
FROM 's3://amzn-s3-demo-bucket/data/venue_fw.txt'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
FIXEDWIDTH 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6';
```
# Caricamento di dati multibyte da Amazon S3
Se i dati includono caratteri multibyte non ASCII (ad esempio caratteri cinesi o cirillici), è necessario caricare i dati nelle colonne VARCHAR. Il tipo di dati VARCHAR supporta caratteri UTF-8 a quattro byte, ma il tipo di dati CHAR accetta solo caratteri ASCII a byte singolo. Non è possibile caricare caratteri a cinque byte o più lunghi nelle tabelle Amazon Redshift. Per ulteriori informazioni su CHAR e VARCHAR, consulta [Tipi di dati](c_Supported_data_types.md).
Per verificare quale codifica utilizza un file di input, utilizza il comando * `file` * di Linux:
```
$ file ordersdata.txt
ordersdata.txt: ASCII English text
$ file uni_ordersdata.dat
uni_ordersdata.dat: UTF-8 Unicode text
```
# Caricamento di file di dati crittografati da Amazon S3
È possibile utilizzare il comando COPY per caricare i file di dati che sono stati caricati in Amazon S3 utilizzando la crittografia lato server, la crittografia lato client o entrambe.
Il comando COPY supporta i seguenti tipi di crittografia Amazon S3:
+ Crittografia lato server con chiavi gestite da Amazon S3 (SSE-S3)
+ AWS KMS keys Crittografia lato server con (SSE-KMS)
+ Crittografia lato server con una chiave root simmetrica lato client
Il comando COPY non supporta i seguenti tipi di crittografia Amazon S3:
+ Crittografia lato server con chiavi fornite dal cliente (SSE-C)
+ Crittografia lato client utilizzando un AWS KMS key
+ Crittografia lato client utilizzando una chiave root asimmetrica fornita dal cliente
Per ulteriori informazioni sulla crittografia Amazon S3, consultare [Protezione dei dati con la crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) e [Protezione dei dati con la crittografia lato client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) nella Guida per l'utente di Amazon Simple Storage Service.
Il comando [UNLOAD](r_UNLOAD.md) crittografa automaticamente i file utilizzando SSE-S3. È inoltre possibile scaricare utilizzando la crittografia SSE-KMS o la crittografia lato client con una chiave simmetrica gestita dal cliente. Per ulteriori informazioni, consulta [Scaricamento di file di dati crittografati](t_unloading_encrypted_files.md)
Il comando COPY riconosce e carica automaticamente i file crittografati utilizzando SSE-S3 e SSE-KMS. È possibile caricare i file crittografati utilizzando una chiave root simmetrica lato client specificando l'opzione ENCRYPTED e fornendo il valore della chiave. Per ulteriori informazioni, consulta [Caricamento di dati crittografati su Amazon S3](t_uploading-encrypted-data.md).
Per caricare i file di dati crittografati lato client, fornisci il valore della chiave root utilizzando il parametro MASTER\$1SYMMETRIC\$1KEY e includi l'opzione ENCRYPTED.
```
COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
MASTER_SYMMETRIC_KEY ''
ENCRYPTED
DELIMITER '|';
```
Per caricare file di dati crittografati compressi con gzip, lzop o bzip2, includi l'opzione GZIP, LZOP o insieme al valore della chiave root e all' BZIP2 opzione ENCRYPTED.
```
COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
MASTER_SYMMETRIC_KEY ''
ENCRYPTED
DELIMITER '|'
GZIP;
```
# Caricamento di dati da Amazon EMR
È possibile utilizzare il comando COPY per caricare dati in parallelo da un cluster Amazon EMR configurato per scrivere file di testo nel File system distribuito Hadoop (HDFS) del cluster sotto forma di file a larghezza fissa, delimitati da caratteri, CSV o formattati JSON.
## Processo per il caricamento dei dati da Amazon EMR
In questa sezione viene illustrato il processo di caricamento dei dati da un cluster Amazon EMR. Le sezioni seguenti forniscono le informazioni dettagliate necessarie per completare ogni fase.
+ **[Fase 1: configurazione delle autorizzazioni IAM](#load-from-emr-steps-configure-iam)**
Gli utenti che creano il cluster Amazon EMR ed eseguono il comando COPY di Amazon Redshift devono disporre delle autorizzazioni necessarie.
+ **[Fase 2: Creazione di un cluster Amazon EMR](#load-from-emr-steps-create-cluster)**
Configurare il cluster per i file di testo di output su Hadoop Distributed File System (HDFS). Saranno necessari l'ID del cluster Amazon EMR e il DNS pubblico principale del cluster (l'endpoint per l'istanza Amazon EC2 che ospita il cluster).
+ **[Fase 3: Recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster Amazon Redshift](#load-from-emr-steps-retrieve-key-and-ips)**
La chiave pubblica consente ai nodi del cluster Amazon Redshift per stabilire connessioni SSH agli host. Sarà utilizzato l'indirizzo IP per ciascun nodo del cluster per configurare i gruppi di sicurezza dell'host in modo da consentire l'accesso dal cluster Amazon Redshift utilizzando questi indirizzi IP.
+ **[Fase 4: Aggiunta della chiave pubblica del cluster Amazon Redshift a ciascun file di chiavi autorizzate dell'host Amazon EC2](#load-from-emr-steps-add-key-to-host)**
Aggiungere la chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate dell'host in modo che l'host riconosca il cluster Amazon Redshift e accetti la connessione SSH.
+ **[Fase 5: Configurazione degli host affinché accettino tutti gli indirizzi IP del cluster Amazon Redshift](#load-from-emr-steps-configure-security-groups)**
Modifica i gruppi di sicurezza dell'istanza Amazon EMR per aggiungere regole di input per accettare gli indirizzi IP di Amazon Redshift.
+ **[Fase 6. esecuzione del comando COPY per il caricamento di dati](#load-from-emr-steps-run-copy)**
Da un database Amazon Redshift, eseguire il comando COPY per caricare i dati in una tabella Amazon Redshift.
## Fase 1: configurazione delle autorizzazioni IAM
Gli utenti che creano il cluster Amazon EMR ed eseguono il comando COPY di Amazon Redshift devono disporre delle autorizzazioni necessarie.
**Per configurare le autorizzazioni IAM**
1. Aggiungi le seguenti autorizzazioni per l'utente che creerà il cluster Amazon EMR.
```
ec2:DescribeSecurityGroups
ec2:RevokeSecurityGroupIngress
ec2:AuthorizeSecurityGroupIngress
redshift:DescribeClusters
```
1. Aggiungi le seguenti autorizzazioni per l'utente o il ruolo IAM che eseguirà il comando COPY.
```
elasticmapreduce:ListInstances
```
1. Aggiungere le seguenti autorizzazioni al ruolo IAM del cluster Amazon EMR.
```
redshift:DescribeClusters
```
## Fase 2: Creazione di un cluster Amazon EMR
Il comando COPY carica i dati dai file nell'file di sistema distribuito Hadoop (HDFS) di Amazon EMR. Quando si crei il cluster Amazon EMR, configurare il cluster per i file di dati di output nell'HDFS del cluster.
**Come creare un cluster Amazon EMR**
1. Crea un cluster Amazon EMR nella stessa AWS regione del cluster Amazon Redshift.
Se il cluster Amazon Redshift si trova in un VPC, il cluster Amazon EMR dovrà trovarsi nello stesso gruppo VPC. Se il cluster Amazon Redshift utilizza la modalità EC2-Classic (cioè, non si trova in un VPC), anche il cluster Amazon EMR dovrà utilizzare la modalità EC2-Classic. Per ulteriori informazioni, consulta [Gestione dei cluster nel cloud privato virtuale (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) nella *Guida alla gestione di Amazon Redshift*.
1. Configurare il cluster per i file di dati di output nell'HDFS del cluster. I nomi dei file HDFS non devono contenere asterischi (\$1) o punti interrogativi (?).
**Importante**
I nomi dei file non devono contenere asterischi (\$1) o punti interrogativi (?).
1. Specificare **No** per l'opzione **Termina automaticamente** nella configurazione del cluster Amazon EMR in modo che il cluster rimanga disponibile mentre viene eseguito il comando COPY.
**Importante**
Se uno qualsiasi dei file di dati viene modificato o cancellato prima del completamento dell'operazione di COPY, si potrebbero ottenere risultati imprevisti o l'operazione di COPY potrebbe fallire.
1. Prendi nota dell'ID e del DNS pubblico principale del cluster (l'endpoint per l'istanza Amazon EC2 che ospita il cluster). Queste informazioni saranno utili per le fasi successive.
## Fase 3: Recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster Amazon Redshift
Sarà utilizzato l'indirizzo IP per ciascun nodo del cluster per configurare i gruppi di sicurezza dell'host in modo da consentire l'accesso dal cluster Amazon Redshift utilizzando questi indirizzi IP.
**Come recuperare la chiave pubblica del cluster Amazon Redshift e gli indirizzi IP dei nodi del cluster tramite la console**
1. Accedere alla console di gestione di Amazon Redshift.
1. Nel riquadro di navigazione scegli **Clusters** (Cluster).
1. Selezionare il cluster dall'elenco.
1. Individuare il gruppo **SSH Ingestion Settings (Impostazioni di inserimento SSH)**.
Prendere nota dei valori di **Cluster Public Key (Chiave pubblica del cluster)** e **Node IP addresses (Indirizzi IP del nodo)**. Queste informazioni saranno utili per le fasi successive.
![\[Screenshot del gruppo Impostazioni di inserimento SSH con Chiave pubblica del cluster e Indirizzi IP dei nodi.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/copy-from-ssh-console-2.png)
Saranno utilizzati gli indirizzi IP privati nella fase 3 per configurare l'host Amazon EC2 affinché accetti la connessione da Amazon Redshift.
Per recuperare la chiave pubblica del cluster e gli indirizzi IP dei nodi del cluster tramite la CLI di Amazon Redshift, emettere il comando describe-clusters. Esempio:
```
aws redshift describe-clusters --cluster-identifier
```
La risposta includerà un ClusterPublicKey valore e l'elenco di indirizzi IP privati e pubblici, simili al seguente:
```
{
"Clusters": [
{
"VpcSecurityGroups": [],
"ClusterStatus": "available",
"ClusterNodes": [
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "LEADER",
"PublicIPAddress": "10.nnn.nnn.nnn"
},
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "COMPUTE-0",
"PublicIPAddress": "10.nnn.nnn.nnn"
},
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "COMPUTE-1",
"PublicIPAddress": "10.nnn.nnn.nnn"
}
],
"AutomatedSnapshotRetentionPeriod": 1,
"PreferredMaintenanceWindow": "wed:05:30-wed:06:00",
"AvailabilityZone": "us-east-1a",
"NodeType": "dc2.large",
"ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift",
...
...
}
```
Per recuperare la chiave pubblica del cluster e gli indirizzi IP dei nodi del cluster per il cluster con l'API di Amazon Redshift, utilizzare l'operazione `DescribeClusters`. Per ulteriori informazioni, consulta [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) nella Amazon Redshift *CLI Guide o [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)nella Amazon Redshift API Guide*.
## Fase 4: Aggiunta della chiave pubblica del cluster Amazon Redshift a ciascun file di chiavi autorizzate dell'host Amazon EC2
Aggiungere la chiave pubblica del cluster a ciascun file delle chiavi autorizzate dell'host per tutti i nodi del cluster Amazon EMR in modo che gli host riconoscano Amazon Redshift e accettino la connessione SSH.
**Come aggiungere la chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate di ciascun host**
1. Accedere all'host tramite una connessione SSH.
Per ulteriori informazioni sulla connessione a un'istanza che utilizza SSH, consultare [Connessione all'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) nella *Guida per l'utente di Amazon EC2*.
1. Copiare la chiave pubblica di Amazon Redshift dalla console o dal testo di risposta della CLI.
1. Copiare e incollare i contenuti della chiave pubblica nel file `/home//.ssh/authorized_keys` nell'host. Includere la stringa completa, compreso il prefisso "`ssh-rsa` " e il suffisso "`Amazon-Redshift`". Ad esempio:
```
ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift
```
## Fase 5: Configurazione degli host affinché accettino tutti gli indirizzi IP del cluster Amazon Redshift
Per consentire il traffico in entrata verso le istanze dell'host, modificare il gruppo di sicurezza e aggiungere una regola in entrata per ciascun nodo del cluster Amazon Redshift. In **Type (Tipo)**, seleziona SSH con il protocollo TCP sulla porta 22. In **Source** (Origine), inserisci gli indirizzi IP privati dei nodi cluster di Amazon Redshift recuperati in [Fase 3: Recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster Amazon Redshift](#load-from-emr-steps-retrieve-key-and-ips). Per informazioni sull'aggiunta di regole a un gruppo di sicurezza Amazon EC2, consultare [Autorizzazione del traffico in entrata per le istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) nella *Guida per l'utente di Amazon EC2*.
## Fase 6. esecuzione del comando COPY per il caricamento di dati
Eseguire un comando [COPY](r_COPY.md) per effettuare la connessione al cluster Amazon EMR e caricare i dati in una tabella Amazon Redshift. Il cluster Amazon EMR deve continuare a funzionare fino al completamento del comando COPY. Ad esempio, non configurare la terminazione automatica del cluster.
**Importante**
Se uno qualsiasi dei file di dati viene modificato o cancellato prima del completamento dell'operazione di COPY, si potrebbero ottenere risultati imprevisti o l'operazione di COPY potrebbe fallire.
Nel comando COPY, specificare l'ID cluster Amazon EMR e il percorso del file HDFS e il nome del file.
```
COPY sales
FROM 'emr://myemrclusterid/myoutput/part*' CREDENTIALS
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
```
È possibile utilizzare i caratteri jolly asterisco (`*`) e punto interrogativo (`?`) come parte dell'argomento del nome file. Ad esempio, `part*` carica i file `part-0000`, `part-0001` e così via. Se specifichi solo il nome di una cartella, COPY tenta di caricare tutti i file nella cartella.
**Importante**
Se utilizzi caratteri jolly o solo il nome della cartella, verifica che non vengano caricati file indesiderati o che il comando COPY fallisca. Ad esempio, alcuni processi potrebbero scrivere un file di log nella cartella di output.
# Caricamento di dati da host remoti
È possibile utilizzare il comando COPY per caricare dati in parallelo da uno o più host remoti, quali istanze Amazon EC2 o altri computer. COPY si connette agli host remoti utilizzando SSH ed esegue comandi sugli host remoti per generare output di testo.
L'host remoto può essere un'istanza Linux di Amazon EC2 o un altro computer Unix o Linux configurato per accettare connessioni SSH. Questa guida presuppone che l'host remoto si trovi in un'istanza Amazon EC2. Se la procedura è diversa per un altro computer, la guida indicherà la differenza.
Amazon Redshift può connettersi a più host e può aprire più connessioni SSH per ogni host. Amazon Redshift invia un comando univoco attraverso ogni connessione per generare output di testo per l'output standard dell'host, che legge quindi come un file di testo.
## Prima di iniziare
Prima di iniziare, devi disporre dei seguenti requisiti:
+ Una o più macchine host, come le istanze Amazon EC2, a cui è possibile effettuare la connessione utilizzando SSH.
+ Origini dati negli host.
Saranno forniti i comandi che il cluster Amazon Redshift eseguirà sugli host per generare l'output di testo. Una volta che il cluster si connette a un host, il comando COPY esegue i comandi, legge il testo dall'output standard degli host e carica i dati in parallelo in una tabella Amazon Redshift. L'output di testo deve essere in un formato importabile dal comando COPY. Per ulteriori informazioni, consulta [Preparazione dei dati di input](t_preparing-input-data.md)
+ Accesso agli host dal computer.
Per un'istanza Amazon EC2, per accedere all'host verrà utilizzata una connessione SSH. Devi accedere all'host per aggiungere la chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate dell'host.
+ Un cluster Amazon Redshift in esecuzione.
Per informazioni su come avviare un cluster, consultare [Guida alle operazioni di base di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/).
## Processo di caricamento dei dati
Questa sezione illustra il processo di caricamento dei dati da host remoti. Le sezioni seguenti forniscono le informazioni dettagliate necessarie per completare ogni fase.
+ **[Fase 1: recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster](#load-from-host-steps-retrieve-key-and-ips)**
La chiave pubblica consente ai nodi del cluster Amazon Redshift di stabilire connessioni SSH agli host remoti. Sarà utilizzato l'indirizzo IP per ciascun nodo del cluster per configurare i gruppi di sicurezza dell'host o del firewall in modo da consentire l'accesso dal cluster Amazon Redshift utilizzando questi indirizzi IP.
+ **[Fase 2: Aggiunta della chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate di ciascun host](#load-from-host-steps-add-key-to-host)**
Aggiungere la chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate dell'host in modo che l'host riconosca il cluster Amazon Redshift e accetti la connessione SSH.
+ **[Fase 3: Configurazione dell'host affinché accetti tutti gli indirizzi IP del cluster Amazon Redshift](#load-from-host-steps-configure-security-groups)**
Per Amazon EC2, modifica i gruppi di sicurezza dell'istanza per aggiungere regole di input per accettare gli indirizzi IP di Amazon Redshift. Per gli altri host, modificare il firewall in modo che i nodi Amazon Redshift possano stabilire connessioni SSH all'host remoto.
+ **[Fase 4: ottenere una chiave pubblica per l'host](#load-from-host-steps-get-the-host-key)**
È possibile specificare che Amazon Redshift deve utilizzare la chiave pubblica per identificare l'host. Devi individuare la chiave pubblica e copiare il testo nel file manifesto.
+ **[Fase 5: creazione di un file manifest](#load-from-host-steps-create-manifest)**
Il manifest è un file di testo in formato JSON con i dettagli necessari ad Amazon Redshift per effettuare la connessione agli host e recuperare i dati.
+ **[Fase 6: Caricamento del file manifest in un bucket Amazon S3](#load-from-host-steps-upload-manifest)**
Amazon Redshift legge il manifest e utilizza tali informazioni per effettuare la connessione all'host remoto. Se il bucket Amazon S3 non si trova nella stessa regione del cluster Amazon Redshift, è necessario utilizzare l'opzione [REGION](copy-parameters-data-source-s3.md#copy-region) per specificare la regione in cui si trovano i dati.
+ **[Fase 7: esecuzione del comando COPY per il caricamento di dati](#load-from-host-steps-run-copy)**
Da un database Amazon Redshift, eseguire il comando COPY per caricare i dati in una tabella Amazon Redshift.
## Fase 1: recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster
Sarà utilizzato l'indirizzo IP per ciascun nodo del cluster per configurare i gruppi di sicurezza dell'host in modo da consentire l'accesso dal cluster Amazon Redshift utilizzando questi indirizzi IP.
**Per recuperare la chiave pubblica del cluster e gli indirizzi IP dei nodi del cluster tramite la console**
1. Accedere alla console di gestione di Amazon Redshift.
1. Nel riquadro di navigazione scegli **Clusters** (Cluster).
1. Selezionare il cluster dall'elenco.
1. Individuare il gruppo **SSH Ingestion Settings (Impostazioni di inserimento SSH)**.
Prendere nota dei valori di **Cluster Public Key (Chiave pubblica del cluster)** e **Node IP addresses (Indirizzi IP del nodo)**. Queste informazioni saranno utili per le fasi successive.
![\[Screenshot del gruppo Impostazioni di inserimento SSH con Chiave pubblica del cluster e Indirizzi IP dei nodi.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/copy-from-ssh-console-2.png)
Per configurare l'host affinché accetti la connessione da Amazon Redshift, saranno utilizzati gli indirizzi IP della fase 3. A seconda del tipo di host a cui ti connetti e se si trova in un VPC, utilizzerai gli indirizzi IP pubblici o gli indirizzi IP privati.
Per recuperare la chiave pubblica del cluster e gli indirizzi IP dei nodi del cluster tramite la CLI di Amazon Redshift, emettere il comando describe-clusters.
Esempio:
```
aws redshift describe-clusters --cluster-identifier
```
La risposta includerà l'elenco ClusterPublicKey e l'elenco di indirizzi IP privati e pubblici, simili ai seguenti:
```
{
"Clusters": [
{
"VpcSecurityGroups": [],
"ClusterStatus": "available",
"ClusterNodes": [
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "LEADER",
"PublicIPAddress": "10.nnn.nnn.nnn"
},
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "COMPUTE-0",
"PublicIPAddress": "10.nnn.nnn.nnn"
},
{
"PrivateIPAddress": "10.nnn.nnn.nnn",
"NodeRole": "COMPUTE-1",
"PublicIPAddress": "10.nnn.nnn.nnn"
}
],
"AutomatedSnapshotRetentionPeriod": 1,
"PreferredMaintenanceWindow": "wed:05:30-wed:06:00",
"AvailabilityZone": "us-east-1a",
"NodeType": "dc2.large",
"ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift",
...
...
}
```
Per recuperare la chiave pubblica del cluster e gli indirizzi IP del nodo del cluster per il cluster utilizzando l'API Amazon Redshift, utilizza l' DescribeClusters azione. Per ulteriori informazioni, consulta [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) nella Amazon Redshift *CLI Guide o [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)nella Amazon Redshift API Guide*.
## Fase 2: Aggiunta della chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate di ciascun host
Aggiungere la chiave pubblica del cluster a ciascun file delle chiavi autorizzate dell'host in modo che l'host riconosca il cluster Amazon Redshift e accetti la connessione SSH.
**Come aggiungere la chiave pubblica del cluster Amazon Redshift al file di chiavi autorizzate di ciascun host**
1. Accedere all'host tramite una connessione SSH.
Per ulteriori informazioni sulla connessione a un'istanza che utilizza SSH, consultare [Connessione all'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) nella *Guida per l'utente di Amazon EC2*.
1. Copiare la chiave pubblica di Amazon Redshift dalla console o dal testo di risposta della CLI.
1. Copiare e incollare i contenuti della chiave pubblica nel file `/home//.ssh/authorized_keys` nell'host remoto. Il valore `` deve corrispondere al valore per il campo "username" nel file manifest. Includere la stringa completa, compreso il prefisso "`ssh-rsa` " e il suffisso "`Amazon-Redshift`". Ad esempio:
```
ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift
```
## Fase 3: Configurazione dell'host affinché accetti tutti gli indirizzi IP del cluster Amazon Redshift
Se si lavora con un'istanza Amazon EC2 o un cluster Amazon EMR, aggiungere le regole in entrata al gruppo di sicurezza dell'host per consentire il traffico da ogni nodo del cluster Amazon Redshift. In **Type (Tipo)**, seleziona SSH con il protocollo TCP sulla porta 22. In **Origine**, inserire gli indirizzi IP dei nodi del cluster di Amazon Redshift recuperati in [Fase 1: recupero degli indirizzi IP dei nodi del cluster e della chiave pubblica del cluster](#load-from-host-steps-retrieve-key-and-ips). Per informazioni sull'aggiunta di regole a un gruppo di sicurezza Amazon EC2, consultare [Autorizzazione del traffico in entrata per le istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) nella *Guida per l'utente di Amazon EC2*.
Utilizza gli indirizzi IP privati quando:
+ Hai un cluster Amazon Redshift che non si trova in un Virtual Private Cloud (VPC) e un'istanza Amazon EC2 -Classic, entrambi situati nella stessa regione. AWS
+ Hai un cluster Amazon Redshift che si trova in un VPC e un'istanza Amazon EC2 -VPC, entrambi nella stessa regione e nello stesso VPC. AWS
In alternativa, utilizza gli indirizzi IP pubblici.
Per ulteriori informazioni sull'utilizzo di Amazon Redshift in un VPC, consulta [Gestione dei cluster nel cloud privato virtuale (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) nella *Guida alla gestione di Amazon Redshift*.
## Fase 4: ottenere una chiave pubblica per l'host
Facoltativamente, è possibile fornire la chiave pubblica dell'host nel file manifest in modo che Amazon Redshift possa identificare l'host. Il comando COPY non richiede la chiave pubblica dell'host ma, per motivi di sicurezza, consigliamo vivamente di utilizzare una chiave pubblica per prevenire gli attacchi «». man-in-the-middle
È possibile trovare la chiave pubblica dell'host nel seguente percorso, dove `` è il nome univoco della chiave pubblica dell'host:
```
: /etc/ssh/.pub
```
**Nota**
Amazon Redshift supporta solo le chiavi RSA. Non supportiamo le chiavi DSA.
Quando crei il file manifest alla fase 5, incollerai il testo della chiave pubblica nel campo "Public Key" (Chiave pubblica) nella voce del file manifest.
## Fase 5: creazione di un file manifest
Il comando COPY può connettersi a più host tramite SSH e può creare più connessioni SSH per ogni host. COPY esegue un comando attraverso ogni connessione host, quindi carica l'output dai comandi in parallelo nella tabella. Il file manifest è un file di testo in formato JSON che Amazon Redshift utilizza per la connessione all'host. Il file manifest specifica gli endpoint dell'host SSH e i comandi che vengono eseguiti sugli host per restituire i dati ad Amazon Redshift. Facoltativamente, puoi includere la chiave pubblica dell'host, il nome utente di login e un flag obbligatorio per ogni voce.
Crea il file manifest nel computer locale. In un passaggio successivo, il file viene caricato in Amazon S3.
Il file manifest è nel seguente formato:
```
{
"entries": [
{"endpoint":"",
"command": "",
"mandatory":true,
"publickey": "",
"username": ""},
{"endpoint":"",
"command": "",
"mandatory":true,
"publickey": "",
"username": "host_user_name"}
]
}
```
Il file manifest contiene un costrutto "entries" per ogni connessione SSH. Ogni voce rappresenta una singola connessione SSH. È possibile avere più connessioni a un singolo host o più connessioni a più host. Le doppie virgolette sono richieste come mostrato, sia per i nomi dei campi sia per i valori. L'unico valore che non necessita di doppie virgolette è il valore booleano **true** o **false** per il campo obbligatorio.
Di seguito sono descritti i campi del file manifest.
endpoint
L'indirizzo URL o l'indirizzo IP dell'host. Ad esempio, “`ec2-111-222-333.compute-1.amazonaws.com`” o “`22.33.44.56`”
command
Il comando che verrà eseguito dall'host per generare output di testo o binario (gzip, lzop, or bzip2). Il comando può essere qualsiasi comando che l'utente *"host\$1user\$1name"* è autorizzato a eseguire. Il comando può essere semplice come stampare un file o eseguire una query su un database o lanciare uno script. L'output (file di testo o file binario gzip, lzop o bzip2) deve essere in un formato che il comando COPY di Amazon Redshift possa importare. Per ulteriori informazioni, consulta [Preparazione dei dati di input](t_preparing-input-data.md).
publickey
(Facoltativo) La chiave pubblica dell'host. Se fornita, Amazon Redshift userà la chiave pubblica per identificare l'host. Se la chiave pubblica non viene fornita, Amazon Redshift non tenterà l'identificazione dell'host. Ad esempio, se la chiave pubblica dell'host remoto è `ssh-rsa AbcCbaxxx…xxxDHKJ root@amazon.com`, digita il seguente testo nel campo della chiave pubblica: `AbcCbaxxx…xxxDHKJ`.
mandatory
(Facoltativo) Indica se il comando COPY debba fallire se la connessione fallisce. Il valore predefinito è `false`. Se Amazon Redshift non riesce a effettuare almeno una connessione, il comando COPY avrà esito negativo.
username
(Facoltativo) Il nome utente che verrà utilizzato per accedere al sistema host ed eseguire il comando remoto. Il nome di login dell'utente deve essere lo stesso utilizzato per aggiungere la chiave pubblica al file delle chiavi autorizzate nella fase 2. Il nome utente predefinito è "redshift".
Il seguente esempio mostra un manifest completato per aprire quattro connessioni allo stesso host ed eseguire un comando diverso tramite ciascuna connessione:
```
{
"entries": [
{"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com",
"command": "cat loaddata1.txt",
"mandatory":true,
"publickey": "ec2publickeyportionoftheec2keypair",
"username": "ec2-user"},
{"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com",
"command": "cat loaddata2.txt",
"mandatory":true,
"publickey": "ec2publickeyportionoftheec2keypair",
"username": "ec2-user"},
{"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com",
"command": "cat loaddata3.txt",
"mandatory":true,
"publickey": "ec2publickeyportionoftheec2keypair",
"username": "ec2-user"},
{"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com",
"command": "cat loaddata4.txt",
"mandatory":true,
"publickey": "ec2publickeyportionoftheec2keypair",
"username": "ec2-user"}
]
}
```
## Fase 6: Caricamento del file manifest in un bucket Amazon S3
Caricare il file manifest in un bucket Amazon S3. Se il bucket Amazon S3 non si trova nella stessa AWS regione del cluster Amazon Redshift, devi utilizzare l'[REGION](copy-parameters-data-source-s3.md#copy-region)opzione per specificare la AWS regione in cui si trova il manifest. Per ulteriori informazioni sulla creazione di un bucket Amazon S3 e sul caricamento di un file, consultare [Guida per l'utente di Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/).
## Fase 7: esecuzione del comando COPY per il caricamento di dati
Eseguire un comando [COPY](r_COPY.md) per effettuare la connessione all'host e caricare i dati in una tabella Amazon Redshift. Nel comando COPY, specificare il percorso dell'oggetto Amazon S3 esplicito per il file manifest e includere l'opzione SSH. Ad esempio,
```
COPY sales
FROM 's3://amzn-s3-demo-bucket/ssh_manifest'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
DELIMITER '|'
SSH;
```
**Nota**
Se utilizzi la compressione automatica, il comando COPY esegue due operazioni di lettura dati, il che significa che eseguirà il comando remoto due volte. La prima operazione di lettura consiste nel fornire un campione per l'analisi della compressione e la seconda operazione di lettura carica effettivamente i dati. Se la doppia esecuzione del comando remoto può causare un problema, dati i potenziali effetti collaterali, è necessario disattivare la compressione automatica. Per disattivare la compressione automatica, esegui il comando COPY con l'opzione COMPUPDATE impostata su OFF. Per ulteriori informazioni, consulta [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md).
# Caricamento di dati da una tabella Amazon DynamoDB
È possibile utilizzare il comando COPY per caricare una tabella con dati da una singola tabella Amazon DynamoDB.
**Importante**
La tabella Amazon DynamoDB che fornisce i dati deve essere creata nella AWS stessa regione del cluster a meno che non si utilizzi l'opzione per specificare [REGION](copy-parameters-data-source-s3.md#copy-region) la regione in cui si trova AWS la tabella Amazon DynamoDB.
Il comando COPY utilizza l'architettura MPP (Massively Parallel Processing) di Amazon Redshift per leggere e caricare dati in parallelo da una tabella Amazon DynamoDB. È possibile ottenere il massimo dall'elaborazione parallela impostando gli stili di distribuzione nelle tabelle Amazon Redshift. Per ulteriori informazioni, consulta [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md).
**Importante**
Quando il comando COPY legge i dati dalla tabella Amazon DynamoDB, il trasferimento dei dati risultante fa parte del throughput assegnato di quella tabella.
Per evitare di utilizzare quantità eccessive di throughput di lettura assegnato, consigliamo di non caricare i dati dalle tabelle Amazon DynamoDB che si trovano in ambienti di produzione. Se carichi i dati dalle tabelle di produzione, consigliamo di impostare l'opzione READRATIO su un valore molto più basso della percentuale media del throughput assegnato inutilizzato. Un'impostazione READRATIO bassa contribuirà a ridurre al minimo i problemi di throttling. Per utilizzare l'intero throughput assegnato di una tabella Amazon DynamoDB, impostare READRATIO su 100.
Il comando COPY fa corrispondere i nomi degli attributi negli elementi recuperati dalla tabella DynamoDB ai nomi di colonna nella tabella Amazon Redshift esistente utilizzando le seguenti regole:
+ Le colonne di una tabella Amazon Redshift corrispondono senza distinzione tra maiuscole e minuscole agli attributi degli elementi di Amazon DynamoDB. Se una voce nella tabella DynamoDB contiene più attributi che differiscono solo tra maiuscole e minuscole, come Price e PRICE, il comando COPY fallirà.
+ Le colonne della tabella Amazon Redshift che non corrispondono a un attributo nella tabella Amazon DynamoDB vengono caricate come NULL o vuote, a seconda del valore specificato con l'opzione EMPTYASNULL nel comando [COPY](r_COPY.md).
+ Gli attributi di Amazon DynamoDB che non corrispondono a una colonna nella tabella Amazon Redshift vengono scartati. Gli attributi vengono letti prima di essere abbinati, quindi anche gli attributi eliminati utilizzano parte del throughput assegnato della tabella.
+ Sono supportati solo gli attributi di Amazon DynamoDB con tipi di dati STRING e NUMBER scalari. I tipi di dati BINARY e SET di Amazon DynamoDB non sono supportati. Se un comando COPY prova a caricare un attributo con un tipo di dati non supportato, il comando fallirà. Se l'attributo non corrisponde a una colonna della tabella Amazon Redshift, il comando COPY non prova a caricarlo e non genera un errore.
Il comando COPY utilizza la seguente sintassi per caricare i dati da una tabella Amazon DynamoDB:
```
COPY FROM 'dynamodb://'
authorization
readratio '';
```
I valori per *l'autorizzazione* sono le AWS credenziali necessarie per accedere alla tabella Amazon DynamoDB. Se queste credenziali corrispondono a un utente, tale utente deve disporre dell'autorizzazione per le operazioni SCAN e DESCRIBE per la tabella Amazon DynamoDB che viene caricata.
I valori di *autorizzazione* forniscono l' AWS autorizzazione necessaria al cluster per accedere alla tabella Amazon DynamoDB. L'autorizzazione deve includere SCAN e DESCRIBE per la tabella Amazon DynamoDB che viene caricata. Per ulteriori informazioni sulle autorizzazioni richieste, consultare [Autorizzazioni IAM per COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Il metodo preferito per l'autenticazione è specificare il parametro IAM\$1ROLE e fornire l'Amazon Resource Name (ARN) per un ruolo IAM con le autorizzazioni necessarie. Per ulteriori informazioni, consulta [Controllo degli accessi basato sui ruoli](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based).
Per autenticarsi utilizzando il parametro IAM\$1ROLE ** e ** come mostrato nella sintassi seguente.
```
IAM_ROLE 'arn:aws:iam:::role/'
```
L'esempio seguente mostra l'autenticazione utilizzando un ruolo IAM.
```
COPY favoritemovies
FROM 'dynamodb://ProductCatalog'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
```
Per ulteriori informazioni su altre opzioni di autorizzazione, consulta [Parametri di autorizzazione](copy-parameters-authorization.md)
Se desideri convalidare i dati senza caricare effettivamente la tabella, utilizza l'opzione NOLOAD con il comando [COPY](r_COPY.md).
L'esempio seguente carica la tabella FAVORITEMOVIES con i dati della tabella DynamoDB. my-favorite-movies-table L'attività di lettura può utilizzare fino al 50% del throughput assegnato.
```
COPY favoritemovies FROM 'dynamodb://my-favorite-movies-table'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
READRATIO 50;
```
Per massimizzare il throughput, il comando COPY carica i dati da una tabella Amazon DynamoDB in parallelo in tutti i nodi di calcolo nel cluster.
## Throughput assegnata con la compressione automatica
Per impostazione predefinita, il comando COPY applica la compressione automatica ogni volta che specifichi una tabella di destinazione vuota senza codifica di compressione. L'analisi della compressione automatica inizialmente campiona un numero elevato di righe dalla tabella Amazon DynamoDB. La dimensione del campione si basa sul valore del parametro COMPROWS. La versione predefinita è di 100.000 per sezione.
Dopo il campionamento, le righe di esempio vengono scartate e viene caricata l'intera tabella. Di conseguenza, molte righe vengono lette due volte. Per ulteriori informazioni sul funzionamento della compressione automatica, consultare [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md).
**Importante**
Quando il comando COPY legge i dati dalla tabella Amazon DynamoDB, incluse le righe utilizzate per il campionamento, il trasferimento dei dati risultante fa parte del throughput assegnato di quella tabella.
## Caricamento di dati multibyte da Amazon DynamoDB
Se i dati includono caratteri multibyte non ASCII (ad esempio caratteri cinesi o cirillici), è necessario caricare i dati nelle colonne VARCHAR. Il tipo di dati VARCHAR supporta caratteri UTF-8 a quattro byte, ma il tipo di dati CHAR accetta solo caratteri ASCII a byte singolo. Non è possibile caricare caratteri a cinque byte o più lunghi nelle tabelle Amazon Redshift. Per ulteriori informazioni su CHAR e VARCHAR, consulta [Tipi di dati](c_Supported_data_types.md).
# Verifica del caricamento corretto dei dati
Al termine dell'operazione di caricamento, eseguire una query sulla tabella del sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) per verificare che i file previsti siano stati caricati. Esegui il comando COPY e carica la verifica all'interno della stessa transazione in modo che, in caso di problemi con il carico, sia possibile eseguire il rollback dell'intera transazione.
La seguente query restituisce le voci per il caricamento delle tabelle nel database TICKIT:
```
SELECT query, trim(filename) AS filename, curtime, status
FROM stl_load_commits
WHERE filename like '%tickit%' order by query;
query | filename | curtime | status
-------+---------------------------+----------------------------+--------
22475 | tickit/allusers_pipe.txt | 2013-02-08 20:58:23.274186 | 1
22478 | tickit/venue_pipe.txt | 2013-02-08 20:58:25.070604 | 1
22480 | tickit/category_pipe.txt | 2013-02-08 20:58:27.333472 | 1
22482 | tickit/date2008_pipe.txt | 2013-02-08 20:58:28.608305 | 1
22485 | tickit/allevents_pipe.txt | 2013-02-08 20:58:29.99489 | 1
22487 | tickit/listings_pipe.txt | 2013-02-08 20:58:37.632939 | 1
22489 | tickit/sales_tab.txt | 2013-02-08 20:58:37.632939 | 1
(6 rows)
```
# Convalida dei dati di input
Per convalidare i dati nei file di input di Amazon S3 o nella tabella Amazon DynamoDB prima di caricare effettivamente i dati, utilizzare l'opzione NOLOAD con il comando [COPY](r_COPY.md). Utilizza NOLOAD con gli stessi comandi e le stesse opzioni di COPY che utilizzeresti per caricare i dati. NOLOAD verifica l'integrità di tutti i dati senza caricarli nel database. L'opzione NOLOAD visualizza eventuali errori che si verificano se avessi provato a caricare i dati.
Ad esempio, se è stato specificato un percorso di Amazon S3 errato per il file di input, Amazon Redshift restituisce il seguente errore.
```
ERROR: No such file or directory
DETAIL:
-----------------------------------------------
Amazon Redshift error: The specified key does not exist
code: 2
context: S3 key being read :
location: step_scan.cpp:1883
process: xenmaster [pid=22199]
-----------------------------------------------
```
Per la risoluzione dei messaggi di errore, consultare [Riferimento per gli errori di caricamento](r_Load_Error_Reference.md).
Per un esempio di utilizzo dell'opzione NOLOAD, consulta [Comando COPY con l'opzione NOLOAD](r_COPY_command_examples.md#r_COPY_command_examples-load-noload-option).
# Caricamento di tabelle con compressione automatica
È possibile applicare manualmente le codifiche di compressione alle colonne delle tabelle, in base alla propria valutazione dei dati. In alternativa, è possibile utilizzare il comando COPY con COMPUPDATE impostato su ON per analizzare e applicare automaticamente la compressione in base ai dati di esempio.
È possibile utilizzare la compressione automatica quando crei e carichi una nuova tabella. Il comando COPY esegue un'analisi di compressione. È anche possibile eseguire un'analisi di compressione senza caricare dati o modificare la compressione in una tabella eseguendo il comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) in una tabella già popolata. Ad esempio, è possibile eseguire ANALYZE COMPRESSION quando si desidera analizzare la compressione su una tabella per un utilizzo futuro, mantenendo al contempo le istruzioni DDL (Data Definition Language) esistenti.
La compressione automatica equilibra le prestazioni globali quando si scelgono le codifiche di compressione. Le prestazioni delle scansioni a intervallo limitato potrebbero risultare scadenti se le colonne di chiave di ordinamento vengono compresse più delle altre colonne nella stessa query. Di conseguenza, la compressione automatica salta la fase di analisi dei dati sulle colonne chiave di ordinamento e mantiene i tipi di codifica definiti dall'utente.
La compressione automatica sceglie la codifica RAW se non è stato definito esplicitamente un tipo di codifica. ANALYZE COMPRESSION si comporta allo stesso modo. Per ottenere prestazioni ottimali delle query, prendere in considerazione l'utilizzo di RAW per le chiavi di ordinamento.
## Come funziona la compressione automatica
Quando il parametro COMPUPDATE è impostato su ON, il comando COPY applica la compressione automatica ogni volta che esegui il comando COPY con una tabella di destinazione vuota e tutte le colonne della tabella hanno codifica RAW o nessuna codifica.
Per applicare la compressione automatica a una tabella vuota, indipendentemente dalle codifiche di compressione attuali, esegui il comando COPY con l'opzione COMPUPDATE impostata su ON. Per disattivare la compressione automatica, esegui il comando COPY con l'opzione COMPUPDATE impostata su OFF.
Non è possibile applicare la compressione automatica a una tabella che contiene già dati.
**Nota**
L'analisi della compressione automatica richiede un numero sufficiente di righe nei dati di carico (almeno 100.000 righe per sezione) per generare un campione significativo.
La compressione automatica esegue queste operazioni in background come parte della transazione di caricamento:
1. Un campione iniziale di righe viene caricato dal file di input. La dimensione del campione si basa sul valore del parametro COMPROWS. Il valore predefinito è 100,000.
1. Le opzioni di compressione vengono scelte per ogni colonna.
1. Le righe di esempio vengono rimosse dalla tabella.
1. La tabella viene ricreata con le codifiche di compressione scelte.
1. L'intero file di input viene caricato e compresso utilizzando le nuove codifiche.
Dopo aver eseguito il comando COPY, la tabella viene completamente caricata, compressa ed è pronta per l'uso. Se carichi più dati in un secondo momento, le righe aggiunte vengono compresse in base alla codifica esistente.
Se desideri eseguire solo un'analisi di compressione, esegui ANALYZE COMPRESSION, che è più efficiente rispetto all'esecuzione di un COPY completo. Quindi è possibile valutare i risultati per decidere se utilizzare la compressione automatica o ricreare manualmente la tabella.
La compressione automatica è supportata solo per il comando COPY. In alternativa, è possibile applicare manualmente la codifica della compressione quando crei la tabella. Per informazioni sulla codifica della compressione manuale, consultare [Compressione delle colonne per ridurre la dimensione dei dati archiviati](t_Compressing_data_on_disk.md).
## Esempio di compressione automatica
In questo esempio, presumi che il database TICKIT contenga una copia della tabella LISTING denominata BIGLIST e desideri applicare la compressione automatica a questa tabella quando viene caricata con circa 3 milioni di righe.
**Per caricare e comprimere automaticamente la tabella**
1. Assicurati che la tabella sia vuota. È possibile applicare la compressione automatica solo a una tabella vuota:
```
TRUNCATE biglist;
```
1. Caricare la tabella con un singolo comando COPY. Sebbene la tabella sia vuota, potrebbe essere stata specificata una codifica precedente. Per consentire che Amazon Redshift esegua un'analisi di compressione, imposta il parametro COMPUPDATE su ON.
```
COPY biglist FROM 's3://amzn-s3-demo-bucket/biglist.txt'
IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
DELIMITER '|' COMPUPDATE ON;
```
Poiché non viene specificata alcuna opzione COMPROWS, viene utilizzata la dimensione di esempio predefinita e consigliata di 100.000 righe per sezione.
1. Guarda il nuovo schema per la tabella BIGLIST per rivedere gli schemi di codifica scelti automaticamente.
```
SELECT "column", type, encoding
from pg_table_def where tablename = 'biglist';
Column | Type | Encoding
----------------+-----------------------------+----------
listid | integer | az64
sellerid | integer | az64
eventid | integer | az64
dateid | smallint | none
numtickets | smallint | az64
priceperticket | numeric(8,2) | az64
totalprice | numeric(8,2) | az64
listtime | timestamp without time zone | az64
```
1. Verifica che il numero previsto di righe sia stato caricato:
```
select count(*) from biglist;
count
---------
3079952
(1 row)
```
Quando le righe vengono aggiunte successivamente a questa tabella utilizzando le istruzioni COPY o INSERT, vengono applicate le stesse codifiche di compressione.
# Ottimizzazione dello storage per tabelle limitate
Se disponi di una tabella con poche colonne ma un numero molto elevato di righe, le tre colonne di identità dei metadati nascoste (INSERT\$1XID, DELETE\$1XID, ROW\$1ID) utilizzeranno una quantità sproporzionata di spazio su disco per la tabella.
Per ottimizzare la compressione delle colonne nascoste, carica la tabella in un'unica transazione COPY, dove possibile. Se carichi la tabella con più comandi COPY separati, la colonna INSERT\$1XID non eseguirà una corretta compressione. Devi eseguire un'operazione vacuum se utilizzi più comandi COPY, ma questa non migliorerà la compressione di INSERT\$1XID.
# Caricamento dei valori delle colonne predefiniti
È possibile definire un elenco di colonne nel comando COPY. Se una colonna della tabella viene omessa dall'elenco di colonne, COPY caricherà la colonna con il valore fornito dall'opzione DEFAULT specificata nel comando CREATE TABLE o con NULL se l'opzione DEFAULT non è stata specificata.
Se COPY tenta di assegnare NULL a una colonna definita come NOT NULL, il comando COPY non viene eseguito. Per informazioni sull'assegnazione dell'opzione DEFAULT, consultare [CREATE TABLE](r_CREATE_TABLE_NEW.md).
Quando si esegue il caricamento da file di dati in Amazon S3, le colonne nell'elenco di colonne devono essere nello stesso ordine dei campi nel file di dati. Se un campo nel file di dati non presenta una colonna corrispondente nell'elenco di colonne, il comando COPY fallisce.
Durante il caricamento dalla tabella Amazon DynamoDB l'ordine non è importante. Qualsiasi campo negli attributi di Amazon DynamoDB che non corrisponde a una colonna nella tabella Amazon Redshift sarà eliminato.
Le seguenti restrizioni si applicano quando si utilizza il comando COPY per caricare i valori DEFAULT in una tabella:
+ Se una colonna [IDENTITY](r_CREATE_TABLE_NEW.md#identity-clause) è inclusa nell'elenco delle colonne, l'opzione EXPLICIT\$1IDS deve essere specificata anche nel comando [COPY](r_COPY.md), altrimenti il comando COPY fallirà. Allo stesso modo, se una colonna IDENTITY viene omessa dall'elenco delle colonne e viene specificata l'opzione EXPLICIT\$1IDS, l'operazione di COPY fallirà.
+ Poiché l'espressione DEFAULT valutata per una determinata colonna è uguale per tutte le righe caricate, un'espressione DEFAULT che utilizza una funzione RANDOM() assegnerà lo stesso valore tutte le righe.
+ Le espressioni DEFAULT che contengono CURRENT\$1DATE o SYSDATE sono impostate sul timestamp della transazione attuale.
Per un esempio, consultare la sezione relativa al caricamento dei dati da un file con valori predefiniti in [Esempi di COPY](r_COPY_command_examples.md).
# Risoluzione di problemi di caricamento dei dati
Quando carichi i dati nelle tabelle Amazon Redshift, puoi riscontrare errori di Amazon S3, dati di input non validi ed errori del comando COPY. In questa sezione vengono fornite le informazioni relative all’identificazione e alla risoluzione degli errori di caricamento dei dati.
**Topics**
+ [Risoluzione dei problemi di integrazione degli eventi S3 e degli errori del processo COPY JOB](s3-integration-troubleshooting.md)
+ [ServiceException Errori S3](s3serviceexception-error.md)
+ [Tabelle di sistema per la risoluzione di caricamento dei dati](system-tables-for-troubleshooting-data-loads.md)
+ [Errori di caricamento di caratteri multibyte](multi-byte-character-load-errors.md)
+ [Riferimento per gli errori di caricamento](r_Load_Error_Reference.md)
# Risoluzione dei problemi di integrazione degli eventi S3 e degli errori del processo COPY JOB
Utilizza le informazioni seguenti per risolvere i problemi di integrazione degli eventi Amazon S3 e degli errori del processo COPY JOB comuni con Amazon Redshift.
## Creazione dell’integrazione degli eventi S3 non riuscita
Se la creazione dell’integrazione degli eventi S3 non è riuscita, lo stato dell’integrazione è `Inactive`. Assicurati che quanto segue sia corretto per il data warehouse Amazon Redshift.
+ Hai aggiunto il principale autorizzato e l’origine di integrazione corretti per il namespace di destinazione in Amazon Redshift. Per informazioni, consulta [Prerequisiti per la creazione di un’integrazione di eventi S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites).
+ Hai aggiunto la policy basata sulle risorse corretta al bucket Amazon S3 di origine. Per informazioni, consulta [Prerequisiti per la creazione di un’integrazione di eventi S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites).
## I dati Amazon S3 non vengono visualizzati nel database di destinazione
Se i dati del processo COPY JOB non vengono visualizzati, controlla quanto segue.
+ Esegui query su SYS\$1COPY\$1JOB\$1DETAIL per visualizzare se il file Amazon S3 è stato caricato, se l’importazione è in sospeso o se si è verificato un errore. Per ulteriori informazioni, consulta [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md).
+ Consulta STL\$1ERROR o SYS\$1COPY\$1JOB\$1INFO se il file Amazon S3 non è presente o c’è un tempo di attesa imprevisto. Cerca errori nelle credenziali o qualsiasi cosa che suggerisca che l’integrazione non è attiva. Per ulteriori informazioni, consultare [STL\$1ERROR](r_STL_ERROR.md) e [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md).
# ServiceException Errori S3
ServiceException Gli errori s3 più comuni sono causati da una stringa di credenziali formattata in modo errato o errato, dal fatto che il cluster e il bucket si trovano in AWS regioni diverse e autorizzazioni Amazon S3 insufficienti.
La sezione fornisce informazioni sulla risoluzione dei problemi per ogni tipo di errore.
## Stringa di credenziali non valida
Se la stringa delle credenziali non è stata formattata correttamente, riceverai il seguente messaggio di errore:
```
ERROR: Invalid credentials. Must be of the format: credentials
'aws_access_key_id=;aws_secret_access_key=
[;token=]'
```
Verificare che la stringa di credenziali non contenga spazi o interruzioni di riga e sia racchiusa tra virgolette singole.
## ID chiave di accesso non valido
Se l'ID della chiave di accesso non esiste, riceverai il seguente messaggio di errore:
```
[Amazon](500310) Invalid operation: S3ServiceException:The AWS Access Key Id you provided does not exist in our records.
```
Spesso si tratta di un errore di copia e incolla. Verifica che l'ID chiave di accesso sia stato inserito correttamente. Inoltre, se usi le chiavi di sessione temporanee, verifica che il valore per `token` sia impostato.
## Chiave di accesso segreta non valida
Se la chiave di accesso segreta non è corretta, riceverai il seguente messaggio di errore:
```
[Amazon](500310) Invalid operation: S3ServiceException:The request signature we calculated does not match the signature you provided.
Check your key and signing method.,Status 403,Error SignatureDoesNotMatch
```
Spesso si tratta di un errore di copia e incolla. Verifica che la chiave di accesso segreta sia stata inserita correttamente e che sia la chiave corretta per l'ID chiave di accesso.
## Bucket in una regione differente
Il bucket Amazon S3 specificato nel comando COPY deve trovarsi nella stessa AWS regione del cluster. Se il bucket Amazon S3 e il cluster si trovano in regioni differenti, verrà ricevuto un errore simile al seguente:
```
ERROR: S3ServiceException:The bucket you are attempting to access must be addressed using the specified endpoint.
```
È possibile creare un bucket Amazon S3 in una regione specifica selezionando la regione quando si crea il bucket con la console di gestione Amazon S3 oppure specificando un endpoint quando si crea il bucket con la CLI o l'API di Amazon S3. Per ulteriori informazioni, consulta [Caricamento di file in Amazon S3 da usare con COPY](t_uploading-data-to-S3.md).
Per maggiori informazioni sulle regioni di Amazon S3, consultare [Accesso a un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html#access-bucket-intro) nella *Guida per l'utente di Amazon Simple Storage Service*.
In alternativa, puoi specificare la regione utilizzando l'opzione [REGION](copy-parameters-data-source-s3.md#copy-region) con il comando COPY.
## Accesso negato
Se l'utente non dispone di autorizzazioni sufficienti, riceverai il seguente messaggio di errore:
```
ERROR: S3ServiceException:Access Denied,Status 403,Error AccessDenied
```
Una causa possibile è che l'utente identificato dalle credenziali non dispone dell'accesso LIST e GET al bucket Amazon S3. Per altre cause, consulta [Risoluzione dei problemi relativi agli errori di accesso negato (403 Accesso negato) in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
Per informazioni sulla gestione dell'accesso utente ai bucket, consulta [Identity and Access Management in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) nella *Guida per l'utente di Amazon Simple Storage*.
# Tabelle di sistema per la risoluzione di caricamento dei dati
Le seguenti tabelle di sistema Amazon Redshift possono essere utili nella risoluzione di problemi di caricamento dei dati:
+ Esegui la query su [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) per scoprire gli errori che si sono verificati durante carichi specifici.
+ Esegui la query su [STL\$1FILE\$1SCAN](r_STL_FILE_SCAN.md) per visualizzare i tempi di caricamento di file specifici o per vedere se un file specifico è stato letto.
+ Eseguire la query su [STL\$1S3CLIENT\$1ERROR](r_STL_S3CLIENT_ERROR.md) per trovare i dettagli degli errori rilevati durante il trasferimento dei dati da Amazon S3.
**Per trovare e diagnosticare errori di caricamento**
1. Creare una vista o definire una query che restituisca dettagli sugli errori di caricamento. L'esempio seguente unisce la tabella STL\$1LOAD\$1ERRORS alla tabella STV\$1TBL\$1PERM per abbinare la tabella ai nomi effettivi delle tabelle. IDs
```
create view loadview as
(select distinct tbl, trim(name) as table_name, query, starttime,
trim(filename) as input, line_number, colname, err_code,
trim(err_reason) as reason
from stl_load_errors sl, stv_tbl_perm sp
where sl.tbl = sp.id);
```
1. Impostare l'opzione MAXERRORS nel comando COPY su un valore sufficientemente grande da consentire a COPY di restituire informazioni utili sui dati. Se COPY rileva errori, un messaggio di errore indica di consultare la tabella STL\$1LOAD\$1ERRORS per i dettagli.
1. Eseguire una query sulla vista LOADVIEW per visualizzare i dettagli dell'errore. Ad esempio:
```
select * from loadview where table_name='venue';
```
```
tbl | table_name | query | starttime
--------+------------+-------+----------------------------
100551 | venue | 20974 | 2013-01-29 19:05:58.365391
| input | line_number | colname | err_code | reason
+----------------+-------------+---------+----------+--------------------
| venue_pipe.txt | 1 | 0 | 1214 | Delimiter not found
```
1. Risolvere il problema nel file di input o nello script di caricamento, in base alle informazioni restituite dalla vista. Alcuni tipici errori di caricamento da tenere in considerazione includono:
+ Mancata corrispondenza tra i tipi di dati nella tabella e i valori nei campi di dati di input.
+ Mancata corrispondenza tra il numero di colonne nella tabella e il numero di campi nei dati di input.
+ Virgolette non corrispondenti. Amazon Redshift supporta le virgolette singole e doppie; tuttavia, queste virgolette devono essere bilanciate in modo appropriato.
+ Formato date/time errato per i dati nei file di input.
+ Out-of-range valori nei file di input (per colonne numeriche).
+ Numero di valori distinti per una colonna superiore alla limitazione per la sua codifica di compressione.
# Errori di caricamento di caratteri multibyte
Le colonne con un tipo di dati CHAR accettano solo caratteri UTF-8 a byte singolo, fino un valore di byte 127 o 7F esadecimale, che rappresenta anche il set di caratteri ASCII. Le colonne VARCHAR accettano caratteri multibyte UTF-8, fino a un massimo di quattro byte. Per ulteriori informazioni, consulta [Tipi di carattere](r_Character_types.md).
Se una riga nei dati di caricamento contiene un carattere non valido per il tipo di dati della colonna, COPY restituisce un errore e registra una riga nella tabella del log di sistema STL\$1LOAD\$1ERRORS con il numero di errore 1220. Il campo ERR\$1REASON include la sequenza di byte, in esadecimale, per il carattere non valido.
Un'alternativa alla correzione di caratteri non validi nei dati di caricamento è la sostituzione dei caratteri non validi durante il processo di caricamento. Per sostituire i caratteri UTF-8 non validi, specifica l'opzione ACCEPTINVCHARS con il comando COPY. Se l'opzione ACCEPTINVCHARS è impostata, il carattere specificato sostituisce il punto codice. Se l'opzione ACCEPTINVCHARS non è impostata, Amazon Redshift accetta i caratteri come UTF-8 valido. Per ulteriori informazioni, consulta [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars).
Il seguente elenco di punti codice è valido UTF-8, le operazioni COPY non restituiscono un errore se l'opzione ACCEPTINVCHARS non è impostata. Tuttavia, questi punti codice sono caratteri non validi. Puoi utilizzare l'opzione [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars) per sostituire un punto di codice con un carattere specificato. Questi punti di codice includono l'intervallo di valori da `0xFDD0` a `0xFDEF` e valori fino a `0x10FFFF`, terminando con `FFFE` o `FFFF`:
+ `0xFFFE`, `0x1FFFE`, `0x2FFFE`, …, `0xFFFFE`, `0x10FFFE`
+ `0xFFFF`, `0x1FFFF`, `0x2FFFF`, …, `0xFFFFF`, `0x10FFFF`
L'esempio seguente mostra il motivo dell'errore quando COPY prova a caricare il carattere UTF-8 `e0 a1 c7a4` in una colonna CHAR.
```
Multibyte character not supported for CHAR
(Hint: Try using VARCHAR). Invalid char: e0 a1 c7a4
```
Se l'errore è correlato a un tipo di dati VARCHAR, il motivo dell'errore include un codice di errore e la sequenza esadecimale UTF-8 non valida. L'esempio seguente mostra il motivo dell'errore quando COPY prova a caricare il carattere UTF-8 `a4` in un campo VARCHAR.
```
String contains invalid or unsupported UTF-8 codepoints.
Bad UTF-8 hex sequence: a4 (error 3)
```
Nella tabella seguente sono elencate le descrizioni e le soluzioni alternative suggerite per gli errori di caricamento VARCHAR. Se si verifica uno di questi errori, sostituisci il carattere con una sequenza di codice UTF-8 valida o rimuovi il carattere.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/multi-byte-character-load-errors.html)
# Riferimento per gli errori di caricamento
Se si verificano errori durante il caricamento dei dati da un file, esegui una query sulla tabella [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) per identificare l'errore e determinare la possibile spiegazione. La seguente tabella elenca tutti i codici di errore che potrebbero verificarsi durante i caricamenti di dati:
## Codici di errore di caricamento
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/r_Load_Error_Reference.html)
# Creare un’integrazione di eventi S3 per copiare automaticamente i file dai bucket Amazon S3
**Nota**
La versione di anteprima per la copia automatica è terminata. Di conseguenza i cluster di anteprima vengono rimossi automaticamente 30 giorni dopo il termine del periodo di anteprima. Se intendi continuare a utilizzare la copia automatica, consigliamo di ricreare i processi di copia automatica esistenti in un altro cluster Amazon Redshift. Non è supportato l’aggiornamento di un cluster di anteprima alla versione più recente di Amazon Redshift.
Puoi utilizzare un processo di copia automatica per caricare i dati nelle tabelle Amazon Redshift dai file archiviati in Amazon S3. Amazon Redshift rileva quando vengono aggiunti nuovi file Amazon S3 al percorso specificato nel comando COPY ed esegue automaticamente un comando COPY senza che sia necessario creare una pipeline di importazione dei dati esterna. Amazon Redshift consente di tenere traccia in modo semplice dei file caricati. Amazon Redshift stabilisce il numero di file raggruppati per comando COPY. È possibile visualizzare i comandi COPY risultanti nelle viste di sistema.
La prima fase per creare un processo COPY JOB automatico consiste nel creare un’integrazione di eventi S3. Quando viene visualizzato un nuovo file nel bucket di origine Amazon S3, Amazon Redshift gestisce il caricamento dei file nel database utilizzando il comando COPY.
## Prerequisiti per la creazione di un’integrazione di eventi S3
Per configurare l’integrazione di eventi S3, verifica che siano soddisfatti i prerequisiti seguenti.
+ Il bucket Amazon S3 deve avere una policy di bucket che concede diverse autorizzazioni Amazon S3. Ad esempio, la seguente politica di esempio consente le autorizzazioni per il bucket di risorse ospitato `amzn-s3-demo-bucket` in. *us-east-1* Il bucket Amazon S3 e l’integrazione sono nella stessa Regione AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Auto-Copy-Policy-01",
"Effect": "Allow",
"Principal": {
"Service": "redshift.amazonaws.com"
},
"Action": [
"s3:GetBucketNotification",
"s3:PutBucketNotification",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket:*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:redshift:us-east-1:111122223333:integration:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
+ Il cluster con provisioning Amazon Redshift o il namespace Redshift serverless di destinazione deve disporre dell’autorizzazione per accedere al bucket. Verifica che un ruolo IAM collegato al cluster o al namespace serverless disponga di una policy IAM che concede le autorizzazioni appropriate. La policy deve consentire sia `s3:GetObject` per una risorsa bucket come `amzn-s3-demo-bucket` sia `s3:ListBucket` per una risorsa bucket e il relativo contenuto, ad esempio `amzn-s3-demo-bucket/*`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AutoCopyReadId",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
Per aggiungere la policy a un ruolo IAM che ha una relazione di attendibilità per il ruolo, segui la procedura descritta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"redshift.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Se il data warehouse di destinazione è un cluster con provisioning, puoi associare un ruolo IAM al cluster con provisioning utilizzando la scheda **Autorizzazioni del cluster** nei dettagli del cluster sulla console Amazon Redshift. Per informazioni su come collegare un ruolo al cluster con provisioning, consulta [Associazione di ruoli IAM ai cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role-associating-with-clusters.html) nella *Guida alla gestione di Amazon Redshift*.
Se il data warehouse di destinazione è Redshift serverless, puoi collegare un ruolo IAM al namespace serverless utilizzando la scheda **Sicurezza e crittografia** nei dettagli del namespace sulla console Redshift serverless. Per informazioni su come collegare un ruolo al namespace serverless, consulta [Concessione delle autorizzazioni ad Amazon Redshift serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-security-other-services.html) nella *Guida alla gestione di Amazon Redshift.*
+ Il data warehouse Amazon Redshift deve inoltre disporre di una policy delle risorse che consenta il bucket Amazon S3. Se utilizzi la console Amazon Redshift, quando crei l’integrazione di eventi S3, Amazon Redshift fornisce l’opzione **Correggi per me** per aggiungere questa policy al data warehouse Amazon Redshift. Per aggiornare autonomamente una politica delle risorse, è possibile utilizzare il [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/redshift/put-resource-policy.html) AWS CLI comando. Ad esempio, per associare una politica delle risorse al tuo cluster con provisioning di Amazon Redshift per l'integrazione di un evento S3 con un bucket Amazon S3, esegui un comando simile al seguente. AWS CLI L'esempio seguente mostra una policy per uno spazio dei nomi del cluster assegnato nell'account utente for. *us-east-1* Regione AWS *123456789012* Il bucket è denominato. *amzn-s3-demo-bucket*
```
aws redshift put-resource-policy \
--policy file://rs-rp.json \
--resource-arn "arn:aws:redshift: us-east-1:123456789012:namespace/cc4ffe56-ad2c-4fd1-a5a2-f29124a56433"
```
Dove `rs-rp.json` contiene:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "redshift.amazonaws.com"
},
"Action": "redshift:AuthorizeInboundIntegration",
"Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket",
"aws:SourceAccount": 111122223333
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/myRedshiftRole"
},
"Action": "redshift:CreateInboundIntegration",
"Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket",
"aws:SourceAccount": 111122223333
}
}
}
]
}
```
------
Per associare una policy di risorse al tuo spazio dei nomi Redshift Serverless per l'integrazione di un evento S3 con un bucket Amazon S3, esegui un comando simile al seguente. AWS CLI L'esempio seguente mostra una policy per uno spazio dei nomi serverless nell'account utente for. *us-east-1* Regione AWS *123456789012* Il bucket è denominato. *amzn-s3-demo-bucket*
```
aws redshift put-resource-policy \
--policy file://rs-rp.json \
--resource-arn "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1"
```
Dove `rs-rp.json` contiene:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "redshift.amazonaws.com"
},
"Action": "redshift:AuthorizeInboundIntegration",
"Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket",
"aws:SourceAccount": 111122223333
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/myUser"
},
"Action": "redshift:CreateInboundIntegration",
"Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket",
"aws:SourceAccount": 111122223333
}
}
}
]
}
```
------
## Creare un’integrazione di eventi Amazon S3
Per configurare il processo di copia, devi dapprima definire un’integrazione di eventi S3.
------
#### [ Amazon Redshift console ]
**Come creare un’integrazione di eventi Amazon S3 sulla console Amazon Redshift**
1. Accedi a Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Nel riquadro di navigazione sinistro scegli **Integrazione di eventi S3**.
1. Scegli **Crea integrazione di eventi Amazon S3** per aprire la procedura guidata per creare un’integrazione di eventi S3 da utilizzare con la copia automatica. Il bucket Amazon S3 di origine e il data warehouse Amazon Redshift di destinazione devono trovarsi nella stessa Regione AWS. Specifica le informazioni seguenti mentre segui la procedure per creare un’integrazione:
+ **Nome dell'integrazione**: è un identificatore univoco per tutte le integrazioni di cui disponi attualmente Account AWS . Regione AWS
+ **Descrizione**: è un testo che descrive l’integrazione di eventi Amazon S3 per farvi riferimento in un momento successivo.
+ Bucket **S3 di origine: è il bucket** Amazon S3 Account AWS attualmente in uso Regione AWS e rappresenta la fonte di importazione dei dati in Amazon Redshift.
+ **Data warehouse Amazon Redshift**: è il cluster con provisioning Amazon Redshift o il gruppo di lavoro Redshift serverless di destinazione che riceve i dati dall’integrazione.
Se il warehouse Amazon Redshift di destinazione si trova nello stesso account, puoi selezionare la destinazione. Se la destinazione si trova in un account diverso, specifichi l’**ARN del data warehouse Amazon Redshift**. La destinazione deve avere una policy delle risorse con i principali e l’origine di integrazione autorizzati. Se non disponi delle policy delle risorse corrette sulla destinazione e la destinazione si trova nello stesso account, puoi selezionare l’opzione **Correggi per me** per applicare automaticamente le policy delle risorse durante il processo di creazione dell’integrazione. Se il tuo obiettivo è in un altro Account AWS, devi applicare manualmente la politica delle risorse sul magazzino Amazon Redshift.
1. Inserisci fino a 50 **Chiavi** di tag e con un **Valore** facoltativo per fornire metadati aggiuntivi sull’integrazione.
1. Viene visualizzata una pagina di revisione in cui puoi scegliere **Crea integrazione di eventi S3**.
------
#### [ AWS CLI ]
Per creare un'integrazione di eventi Amazon S3 utilizzando il AWS CLI, usa il `create-integration` comando con le seguenti opzioni:
+ `integration-name`: specifica un nome per l’integrazione.
+ `source-arn`: specificare l’ARN del bucket di origine Amazon S3.
+ `target-arn`: specifica l’ARN del namespace della destinazione del cluster con provisioning Amazon Redshift o del gruppo di lavoro Redshift serverless.
L’esempio seguente crea un’integrazione fornendo il nome dell’integrazione, l’ARN di origine e l’ARN di destinazione. L’integrazione non è crittografata.
```
aws redshift create-integration \
--integration-name s3-integration \
--source-arn arn:aws:s3:us-east-1::s3-example-bucket \
--target-arn arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222
{
"IntegrationArn": "arn:aws:redshift:us-east-1:123456789012:integration:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"IntegrationName": "s3-integration",
"SourceArn": "arn:aws:s3:::s3-example-bucket",
"SourceType": "s3-event-notifications",
"TargetArn": "arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"Status": "creating",
"Errors": [],
"CreateTime": "2024-10-09T19:08:52.758000+00:00",
"Tags": []
}
```
Puoi anche utilizzare i seguenti AWS CLI comandi per gestire l'integrazione degli eventi S3.
+ `delete-integration`: specifica un ARN di integrazione per eliminare un’integrazione di eventi S3.
+ `modify-integration`: specifica un ARN di integrazione per modificare il nome o la descrizione (o entrambi) di un’integrazione di eventi S3.
+ `describe-integrations`: specifica un ARN di integrazione per visualizzare le proprietà di un’integrazione di eventi S3.
Consulta la [https://docs.aws.amazon.com/cli/latest/reference/redshift/](https://docs.aws.amazon.com/cli/latest/reference/redshift/) per ulteriori informazioni su questi comandi.
------
Amazon Redshift crea quindi un’integrazione di eventi S3 con l’origine e la destinazione associate, lo stato e le informazioni sullo stato di un processo di copia automatica associato. Puoi visualizzare le informazioni su un’integrazione di eventi S3 sulla console Amazon Redshift scegliendo **Integrazioni di eventi S3** e selezionando l’integrazione per visualizzarne i dettagli. Le integrazioni sono separate da quelle create **Nel mio account** e **Da altri account.** Nell’elenco **Nel mio account** sono visualizzate le integrazioni in cui l’origine e la destinazione si trovano nello stesso account. Nell’elenco **Da altri account** sono visualizzate le integrazioni in cui l’origine è di proprietà di un altro account.
Se elimini un’integrazione di eventi S3, lo stato del processo COPY JOB corrispondente cambia da `1` (attivo) a `0` (inattivo/in sospeso). Tuttavia il processo COPY JOB corrispondente non viene rimosso automaticamente. Se in seguito tenti di creare un processo COPY JOB con lo stesso nome, potrebbe verificarsi un conflitto.
## Creare e monitorare un processo COPY JOB
Dopo avere creato l’integrazione, nella pagina **Dettagli sull’integrazione di eventi S3** relativa all’integrazione che hai creato, scegli **Crea un processo di copia automatica** per accedere ad Amazon Redshift Query Editor V2 dove puoi creare il processo di copia automatica per l’integrazione. Amazon Redshift abbina il bucket della clausola FROM dell’istruzione COPY JOB CREATE al bucket utilizzato nell’integrazione di eventi S3. Per informazioni su come utilizzare Amazon Redshift Query Editor V2, consulta [Esecuzione di query su un database con Amazon Redshift Query Editor V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2.html) nella *Guida alla gestione di Amazon Redshift*. Ad esempio, esegui il comando COPY seguente in Query Editor V2 per creare un processo COPY JOB automatico che abbina il bucket Amazon S3 `s3://amzn-s3-demo-bucket/staging-folder` a un’integrazione di eventi Amazon S3.
```
COPY public.target_table
FROM 's3://amzn-s3-demo-bucket/staging-folder'
IAM_ROLE 'arn:aws:iam::123456789012:role/MyLoadRoleName'
JOB CREATE my_copy_job_name
AUTO ON;
```
È necessario definire un processo COPY JOB una sola volta, in quanto gli stessi parametri verranno utilizzati per le esecuzioni future.
Per definire e gestire un processo COPY JOB, devi disporre dell’autorizzazione. Per informazioni sulla concessione e sulla revoca dell’autorizzazione per un processo COPY JOB, consulta [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md). Per ulteriori informazioni sulla concessione e sulla revoca delle autorizzazioni con ambito per un processo COPY JOB, consulta [Assegnazione delle autorizzazioni con ambito](r_GRANT.md#grant-scoped-syntax) e [Revoca delle autorizzazioni con ambito](r_REVOKE.md#revoke-scoped-permissions).
È possibile gestire le operazioni di caricamento utilizzando le opzioni CREATE, LIST, SHOW, DROP, ALTER e RUN relative ai processi. Per ulteriori informazioni, consulta [COPY JOB](r_COPY-JOB.md).
È possibile eseguire query sulle viste di sistema per vedere lo stato e l'avanzamento del processo COPY JOB. Le viste disponibili sono le seguenti:
+ [SYS\$1COPY\$1JOB](SYS_COPY_JOB.md) – include una riga per ogni processo COPY JOB definito.
+ [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md): include i dettagli sui file in sospeso, con errore e importati per ciascun processo COPY JOB.
+ [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md): contiene i messaggi registrati relativi a un processo COPY JOB.
+ [SYS\$1LOAD\$1HISTORY](SYS_LOAD_HISTORY.md) – include i dettagli sui comandi COPY.
+ [SYS\$1LOAD\$1ERROR\$1DETAIL](SYS_LOAD_ERROR_DETAIL.md) – include i dettagli sugli errori relativi al comando COPY.
+ [SVV\$1COPY\$1JOB\$1INTEGRATIONS](SVV_COPY_JOB_INTEGRATIONS.md): include i dettagli sulle integrazioni di eventi S3.
+ [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) – include gli errori relativi ai comandi COPY.
+ [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) – include le informazioni utilizzate per risolvere i problemi di caricamento dei dati relativi al comando COPY.
Per ulteriori informazioni sulla correzione degli errori relativi all’integrazione di eventi S3, consulta [Risoluzione dei problemi di integrazione degli eventi S3 e degli errori del processo COPY JOB](s3-integration-troubleshooting.md).
Per ottenere l'elenco dei file caricati da un COPY JOB, esegui il seguente comando SQL, ma prima sostituisci**:
```
SELECT job_id, job_name, data_source, copy_query, filename, status, curtime
FROM sys_copy_job copyjob
JOIN stl_load_commits loadcommit
ON copyjob.job_id = loadcommit.copy_job_id
WHERE job_id = ;
```
## Considerazioni sulla creazione dell’integrazione di eventi S3 per la copia automatica
Considera quanto segue quando utilizzi la copia automatica.
+ Puoi creare un massimo di 200 processi COPY JOB per ogni cluster o gruppo di lavoro in un Account AWS.
+ Puoi creare un massimo di 50 integrazioni di eventi S3 per ogni destinazione Amazon Redshift.
+ Non puoi creare un’integrazione di eventi S3 con un bucket Amazon S3 di origine che ha un punto (.) nel nome del bucket.
+ Puoi creare solo un’integrazione di eventi S3 tra la stessa origine e la stessa destinazione. In altre parole può esserci una sola integrazione di eventi S3 tra un bucket Amazon S3 e un data warehouse Amazon Redshift alla volta.
+ Non puoi avere notifiche di eventi esistenti per il tipo di evento `S3_OBJECT_CREATED` definito nel bucket Amazon S3 di origine. Tuttavia, dopo aver creato un'integrazione di eventi S3, puoi aggiornare la notifica degli eventi del bucket Amazon S3 con prefix/suffix un ambito più ristretto. In questo modo, puoi anche `S3_OBJECT_CREATED` configurarne un altro prefix/suffix con altri obiettivi ed evitare conflitti con l'integrazione degli eventi S3. Se riscontri problemi dovuti al fatto che la copia automatica non è stata eseguita come previsto, prepara il AWS CloudTrail registro dell'`s3:PutBucketNotificationConfiguration`azione sul tuo bucket S3 per l'intervallo di tempo in questione al momento del contatto. Supporto AWS
## Regioni supportate
Di seguito sono elencate le Regioni disponibili per la copia automatica.
| Region | Copia automatica |
| --- | --- |
| Africa (Città del Capo) | Disponibilità |
| Asia Pacifico (Hong Kong) | Disponibilità |
| Asia Pacifico (Taipei) | Disponibilità |
| Asia Pacifico (Tokyo) | Disponibilità |
| Asia Pacifico (Seul) | Disponibilità |
| Asia Pacifico (Osaka) | Disponibilità |
| Asia Pacifico (Mumbai) | Disponibilità |
| Asia Pacifico (Hyderabad) | Disponibilità |
| Asia Pacifico (Singapore) | Disponibilità |
| Asia Pacifico (Sydney) | Disponibilità |
| Asia Pacifico (Giacarta) | Disponibilità |
| Asia Pacifico (Melbourne) | Disponibilità |
| Asia Pacifico (Malesia) | Disponibilità |
| Asia Pacifico (Nuova Zelanda) | Non disponibile |
| Asia Pacifico (Thailandia) | Disponibilità |
| Canada (Centrale) | Disponibilità |
| Canada occidentale (Calgary) | Disponibilità |
| Cina (Pechino) | Disponibilità |
| Cina (Ningxia) | Disponibilità |
| Europa (Francoforte) | Disponibilità |
| Europa (Zurigo) | Disponibilità |
| Europa (Stoccolma) | Disponibilità |
| Europa (Milano) | Disponibilità |
| Europa (Spagna) | Disponibilità |
| Europa (Irlanda) | Disponibilità |
| Europa (Londra) | Disponibilità |
| Europa (Parigi) | Disponibilità |
| Israele (Tel Aviv) | Disponibilità |
| Medio Oriente (Emirati Arabi Uniti) | Disponibilità |
| Medio Oriente (Bahrein) | Disponibilità |
| Messico (centrale) | Disponibilità |
| Sud America (San Paolo) | Disponibilità |
| Stati Uniti orientali (Virginia settentrionale) | Disponibilità |
| Stati Uniti orientali (Ohio) | Disponibilità |
| Stati Uniti occidentali (California settentrionale) | Disponibilità |
| Stati Uniti occidentali (Oregon) | Disponibilità |
| AWS GovCloud (Stati Uniti orientali) | Disponibilità |
| AWS GovCloud (Stati Uniti occidentali) | Disponibilità |
# Caricamento di tabelle con comandi DML
Amazon Redshift supporta i comandi DML (Data Manipulation Language) standard (INSERT, UPDATE e DELETE) che è possibile utilizzare per modificare le righe nelle tabelle. È inoltre possibile utilizzare il comando TRUNCATE per eseguire eliminazioni di massa rapide.
**Nota**
Consigliamo l'uso del comando [COPY](r_COPY.md) per caricare grandi quantità di dati. L'utilizzo di singole istruzioni INSERT per popolare una tabella potrebbe essere eccessivamente lento. In alternativa, se i dati sono già presenti in altre tabelle di database Amazon Redshift, utilizzare INSERT INTO... SELECT FROM o CREATE TABLE AS per migliorare le prestazioni. Per informazioni, consulta [INSERT](r_INSERT_30.md) or [CREATE TABLE AS](r_CREATE_TABLE_AS.md).
Se inserisci, aggiorni o elimini un numero significativo di righe in una tabella, rispetto al numero di righe prima delle modifiche, al termine dell'operazione, esegui i comandi ANALYZE e VACUUM nella tabella. Se nell'applicazione si accumula una serie di piccole modifiche, potresti voler programmare l'esecuzione a intervalli regolari dei comandi ANALYZE e VACUUM. Per ulteriori informazioni, consultare [Analisi delle tabelle](t_Analyzing_tables.md) e [Vacuum delle tabelle](t_Reclaiming_storage_space202.md).
**Topics**
+ [Aggiornamento e inserimento di nuovi dati](t_updating-inserting-using-staging-tables-.md)
# Aggiornamento e inserimento di nuovi dati
È possibile aggiungere in modo efficiente nuovi dati a una tabella esistente utilizzando il comando MERGE. Eseguite un'operazione di unione creando una tabella intermedia e quindi utilizzando uno dei metodi descritti in questa sezione per aggiornare la tabella di destinazione dalla tabella intermedia. Per ulteriori informazioni sul comando MERGE, consulta [MERGE](r_MERGE.md).
Gli [Esempi di unione](merge-examples.md) utilizzano un set di dati di esempio per Amazon Redshift, chiamato TICKIT. Come prerequisito, puoi configurare le tabelle e i dati TICKIT seguendo le istruzioni disponibili in [Nozioni di base sulle attività di database comuni](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Informazioni più dettagliate sul set di dati di esempio sono disponibili in [Database di esempio](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html).
## Metodo di unione 1: sostituzione di righe esistenti
Se si sovrascrivono tutte le colonne della tabella di destinazione, il metodo più veloce per eseguire un'unione consiste nel sostituire le righe esistenti. Questa operazione effettua la scansione della tabella di destinazione solo una volta, utilizzando un inner join per eliminare le righe che verranno aggiornate. Una volta eliminate le righe, vengono sostituite insieme alle nuove righe da una singola operazione INSERT dalla tabella di gestione temporanea.
Utilizza questo metodo se tutte le seguenti condizioni sono vere:
+ La tabella di destinazione e la tabella di gestione temporanea contengono le stesse colonne.
+ Intendi sostituire tutti i dati nelle colonne della tabella di destinazione con tutte le colonne della tabella di gestione temporanea.
+ Utilizzerai tutte le righe nella tabella di gestione temporanea nell'unione.
Se uno qualsiasi di questi criteri non si applica, utilizza il Metodo di unione 2: specifica di un elenco di colonne con MERGE, descritto nella sezione seguente.
Se non utilizzi tutte le righe nella tabella di gestione temporanea, è possibile filtrare le istruzioni DELETE e INSERT tramite una clausola WHERE per escludere le righe di cui non è effettivamente in corso la modifica. Tuttavia, se la maggior parte delle righe nella tabella di gestione temporanea non verrà inclusa nell'unione, consigliamo di eseguire un UPDATE e un INSERT in fasi separate, come descritto più avanti in questa sezione.
## Metodo di unione 2: specifica di un elenco di colonne senza usare MERGE
Utilizza questo metodo per aggiornare colonne specifiche nella tabella di destinazione anziché sovrascrivere intere righe. Questo metodo richiede più tempo del metodo precedente perché richiede una fase di aggiornamento aggiuntiva e non usa il comando MERGE. Utilizza questo metodo se una delle seguenti condizioni è vera:
+ Non tutte le colonne nella tabella di destinazione devono essere aggiornate.
+ La maggior parte delle righe nella tabella di gestione temporanea non verrà utilizzata negli aggiornamenti.
**Topics**
+ [Metodo di unione 1: sostituzione di righe esistenti](#merge-method-replace-existing-rows)
+ [Metodo di unione 2: specifica di un elenco di colonne senza usare MERGE](#merge-method-specify-column-list)
+ [Creazione di una tabella di gestione temporanea](merge-create-staging-table.md)
+ [Esecuzione di un'operazione di unione tramite sostituzione di righe esistenti](merge-replacing-existing-rows.md)
+ [Esecuzione di un'operazione di unione tramite specificazione di un elenco di colonne senza l'uso del comando MERGE](merge-specify-a-column-list.md)
+ [Esempi di unione](merge-examples.md)
# Creazione di una tabella di gestione temporanea
La *tabella di gestione temporanea* è una tabella temporanea che contiene tutti i dati che verranno utilizzati per apportare modifiche alla *tabella di destinazione*, inclusi gli aggiornamenti e gli inserimenti.
Un'operazione di unione richiede un join tra la tabella di gestione temporanea e la tabella di destinazione. Per collocare le righe di unione, imposta la chiave di distribuzione della tabella di gestione temporanea sulla stessa colonna della chiave di distribuzione della tabella di destinazione. Ad esempio, se la tabella di destinazione utilizza una colonna chiave esterna come chiave di distribuzione, utilizza la stessa colonna per la chiave di distribuzione della tabella di gestione temporanea. Se crei una tabella di gestione temporanea tramite un'istruzione [CREATE TABLE LIKE](r_CREATE_TABLE_NEW.md#create-table-like), la tabella di gestione temporanea erediterà la chiave di distribuzione dalla tabella padre. Se utilizzi un'istruzione CREATE TABLE AS, la nuova tabella non eredita la chiave di distribuzione. Per ulteriori informazioni, consulta [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md)
Se la chiave di distribuzione non è uguale alla chiave primaria e la chiave di distribuzione non viene aggiornata come parte dell'operazione di unione, aggiungi un predicato di join ridondante alle colonne della chiave di distribuzione per abilitare un join collocato. Ad esempio:
```
where target.primarykey = stage.primarykey
and target.distkey = stage.distkey
```
Per verificare che la query utilizzerà un join collocato, esegui la query con [EXPLAIN](r_EXPLAIN.md) e controlla DS\$1DIST\$1NONE su tutti i join. Per ulteriori informazioni, consulta [Valutazione del piano di query](c_data_redistribution.md)
# Esecuzione di un'operazione di unione tramite sostituzione di righe esistenti
Quando esegui l'operazione di unione descritta nella procedura, inserisci tutti i passaggi, tranne la creazione e l'eliminazione della tabella di gestione temporanea, in un'unica transazione. Verrà eseguito il rollback della transazione se una fase restituisce un errore. L'utilizzo di una singola transazione riduce anche il numero di commit, risparmiando tempo e risorse.
**Per eseguire un'operazione di unione tramite sostituzione di righe esistenti**
1. Creare una tabella di gestione temporanea e quindi popolarla con i dati da unire, come mostrato nel seguente pseudocodice.
```
CREATE temp table stage (like target);
INSERT INTO stage
SELECT * FROM source
WHERE source.filter = 'filter_expression';
```
1. Utilizzate MERGE per eseguire un'unione interna con la tabella intermedia per aggiornare le righe della tabella di destinazione che corrispondono alla tabella intermedia, quindi inserite tutte le righe rimanenti nella tabella di destinazione che non corrispondono alla tabella intermedia.
Ti consigliamo di eseguire le operazioni di aggiornamento e inserimento in un unico comando MERGE.
```
MERGE INTO target
USING stage [optional alias] on (target.primary_key = stage.primary_key)
WHEN MATCHED THEN
UPDATE SET col_name1 = stage.col_name1 , col_name2= stage.col_name2, col_name3 = {expr}
WHEN NOT MATCHED THEN
INSERT (col_name1 , col_name2, col_name3) VALUES (stage.col_name1, stage.col_name2, {expr});
```
1. Rilasciare la tabella di gestione temporanea.
```
DROP TABLE stage;
```
# Esecuzione di un'operazione di unione tramite specificazione di un elenco di colonne senza l'uso del comando MERGE
Quando esegui l'operazione di unione descritta nella procedura, inserisci tutti i passaggi in un'unica transazione. Verrà eseguito il rollback della transazione se una fase restituisce un errore. L'utilizzo di una singola transazione riduce anche il numero di commit, risparmiando tempo e risorse.
**Per eseguire un'operazione di unione tramite specificazione di un elenco di colonne**
1. Inserisci l'intera operazione in un unico blocco di transazioni.
```
BEGIN transaction;
…
END transaction;
```
1. Creare una tabella di gestione temporanea e quindi popolarla con i dati da unire, come mostrato nel seguente pseudocodice.
```
create temp table stage (like target);
insert into stage
select * from source
where source.filter = 'filter_expression';
```
1. Aggiornare la tabella di destinazione tramite un inner join con la tabella di gestione temporanea.
+ Nella clausola UPDATE, elencare in modo esplicito le colonne da aggiornare.
+ Eseguire un inner join con la tabella di gestione temporanea.
+ Se la chiave di distribuzione è diversa dalla chiave primaria e la chiave di distribuzione non viene aggiornata, aggiungere un predicato di join ridondante alle colonne della chiave di distribuzione per abilitare un join collocato. Per verificare che la query utilizzerà un join collocato, esegui la query con [EXPLAIN](r_EXPLAIN.md) e controlla DS\$1DIST\$1NONE su tutti i join. Per ulteriori informazioni, consulta [Valutazione del piano di query](c_data_redistribution.md)
+ Se la tabella di destinazione è ordinata per timestamp, aggiungere un predicato per sfruttare le scansioni a intervallo limitato nella tabella di destinazione. Per ulteriori informazioni, consulta [Best practice di Amazon Redshift per la progettazione di query](c_designing-queries-best-practices.md).
+ Se non utilizzi tutte le righe nell'unione, aggiungi una clausola per filtrare le righe che desideri modificare. Ad esempio, aggiungere un filtro disuguaglianza a una o più colonne per escludere le righe che non sono state modificate.
+ Inserire le operazioni di aggiornamento, eliminazione e inserimento in un singolo blocco di transazione, in modo che in caso di problemi venga eseguito il rollback.
Ad esempio:
```
begin transaction;
update target
set col1 = stage.col1,
col2 = stage.col2,
col3 = 'expression'
from stage
where target.primarykey = stage.primarykey
and target.distkey = stage.distkey
and target.col3 > 'last_update_time'
and (target.col1 != stage.col1
or target.col2 != stage.col2
or target.col3 = 'filter_expression');
```
1. Eliminare le righe non necessarie dalla tabella di gestione temporanea tramite un inner join con la tabella di destinazione. Alcune righe nella tabella di destinazione corrispondono già alle righe corrispondenti nella tabella di gestione temporanea e altre sono state aggiornate nella fase precedente. In entrambi i casi, non sono necessarie per l'inserimento.
```
delete from stage
using target
where stage.primarykey = target.primarykey;
```
1. Inserire tutte le righe rimanenti dalla tabella di gestione temporanea. Utilizzare lo stesso elenco di colonne nella clausola VALUES utilizzato nell'istruzione UPDATE nella fase due.
```
insert into target
(select col1, col2, 'expression'
from stage);
end transaction;
```
1. Rilasciare la tabella di gestione temporanea.
```
drop table stage;
```
# Esempi di unione
Negli esempi seguenti viene eseguita un'unione per aggiornare la tabella SALES. Il primo esempio utilizza il metodo più semplice di eliminazione dalla tabella di destinazione e quindi l'inserimento di tutte le righe dalla tabella di gestione temporanea. La seconda fase richiede l'aggiornamento su colonne selezionate nella tabella di destinazione, quindi include una fase di aggiornamento aggiuntiva.
Gli [Esempi di unione](#merge-examples) utilizzano un set di dati di esempio per Amazon Redshift, chiamato TICKIT. Come prerequisito, puoi configurare le tabelle e i dati TICKIT seguendo le istruzioni disponibili in [Nozioni di base sulle attività di database comuni](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Informazioni più dettagliate sul set di dati di esempio sono disponibili in [Database di esempio](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html).
**Origine dati di unione di esempio**
Gli esempi in questa sezione richiedono un'origine dati di esempio che includa sia gli aggiornamenti sia gli inserimenti. Per gli esempi, creeremo una tabella di esempio denominata SALES\$1UPDATE che utilizza i dati dalla tabella SALES. Popoleremo la nuova tabella con dati casuali che rappresentano nuove attività di vendita per dicembre. Utilizzeremo la tabella di esempio SALES\$1UPDATE per creare la tabella di gestione temporanea negli esempi che seguono.
```
-- Create a sample table as a copy of the SALES table.
create table tickit.sales_update as
select * from tickit.sales;
-- Change every fifth row to have updates.
update tickit.sales_update
set qtysold = qtysold*2,
pricepaid = pricepaid*0.8,
commission = commission*1.1
where saletime > '2008-11-30'
and mod(sellerid, 5) = 0;
-- Add some new rows to have inserts.
-- This example creates a duplicate of every fourth row.
insert into tickit.sales_update
select (salesid + 172456) as salesid, listid, sellerid, buyerid, eventid, dateid, qtysold, pricepaid, commission, getdate() as saletime
from tickit.sales_update
where saletime > '2008-11-30'
and mod(sellerid, 4) = 0;
```
**Esempio di un'unione che sostituisce le righe esistenti in base alle chiavi di corrispondenza**
Il seguente script utilizza la tabella SALES\$1UPDATE per eseguire un'operazione di unione nella tabella SALES con nuovi dati per l'attività di vendita di dicembre. Questo esempio sostituisce le righe della tabella SALES che contengono aggiornamenti. Per questo esempio, vogliamo aggiornare le colonne QTYSOLD e PRICEPAID e non modificare COMMISSION e SALETIME.
```
MERGE into tickit.sales
USING tickit.sales_update sales_update
on ( sales.salesid = sales_update.salesid
and sales.listid = sales_update.listid
and sales_update.saletime > '2008-11-30'
and (sales.qtysold != sales_update.qtysold
or sales.pricepaid != sales_update.pricepaid))
WHEN MATCHED THEN
update SET qtysold = sales_update.qtysold,
pricepaid = sales_update.pricepaid
WHEN NOT MATCHED THEN
INSERT (salesid, listid, sellerid, buyerid, eventid, dateid, qtysold , pricepaid, commission, saletime)
values (sales_update.salesid, sales_update.listid, sales_update.sellerid, sales_update.buyerid, sales_update.eventid,
sales_update.dateid, sales_update.qtysold , sales_update.pricepaid, sales_update.commission, sales_update.saletime);
-- Drop the staging table.
drop table tickit.sales_update;
-- Test to see that commission and salestime were not impacted.
SELECT sales.salesid, sales.commission, sales.salestime, sales_update.commission, sales_update.salestime
FROM tickit.sales
INNER JOIN tickit.sales_update sales_update
ON
sales.salesid = sales_update.salesid
AND sales.listid = sales_update.listid
AND sales_update.saletime > '2008-11-30'
AND (sales.commission != sales_update.commission
OR sales.salestime != sales_update.salestime);
```
**Esempio di un'unione che specifica un elenco di colonne senza usare MERGE**
L'esempio seguente esegue un'operazione di unione per aggiornare SALES con i nuovi dati per l'attività di vendita di dicembre. Sono necessari dati di esempio che includano sia gli aggiornamenti sia gli inserimenti, oltre alle righe che non sono state modificate. Per questo esempio, vogliamo aggiornare le colonne QTYSOLD e PRICEPAID e non modificare COMMISSION e SALETIME. Il seguente script utilizza la tabella SALES\$1UPDATE per eseguire un'operazione di unione nella tabella SALES.
```
-- Create a staging table and populate it with rows from SALES_UPDATE for Dec
create temp table stagesales as select * from sales_update
where saletime > '2008-11-30';
-- Start a new transaction
begin transaction;
-- Update the target table using an inner join with the staging table
-- The join includes a redundant predicate to collocate on the distribution key –- A filter on saletime enables a range-restricted scan on SALES
update sales
set qtysold = stagesales.qtysold,
pricepaid = stagesales.pricepaid
from stagesales
where sales.salesid = stagesales.salesid
and sales.listid = stagesales.listid
and stagesales.saletime > '2008-11-30'
and (sales.qtysold != stagesales.qtysold
or sales.pricepaid != stagesales.pricepaid);
-- Delete matching rows from the staging table
-- using an inner join with the target table
delete from stagesales
using sales
where sales.salesid = stagesales.salesid
and sales.listid = stagesales.listid;
-- Insert the remaining rows from the staging table into the target table
insert into sales
select * from stagesales;
-- End transaction and commit
end transaction;
-- Drop the staging table
drop table stagesales;
```
# Esecuzione di una copia completa
Una copia completa ricrea e ripopola una tabella tramite inserimento di massa, che ordina automaticamente la tabella. Se una tabella ha una regione ampia e non ordinata, una copia completa è molto più veloce di un vacuum. Ti consigliamo di effettuare aggiornamenti simultanei durante un'operazione di copia completa solo se riesci a tenerne traccia. Una volta completato il processo, sposta gli aggiornamenti delta nella nuova tabella. Un'operazione VACUUM supporta automaticamente gli aggiornamenti simultanei.
È possibile scegliere uno dei seguenti metodi per creare una copia della tabella originale:
+ Utilizza la tabella con DDL originale.
Se è disponibile CREATE TABLE DDL, questo è il metodo più veloce e preferito. Se crei una nuova tabella, è possibile specificare tutti gli attributi di tabella e colonna, comprese la chiave primaria e le chiavi esterne. È possibile trovare il DDL originale utilizzando la funzione SHOW TABLE.
+ Utilizza CREATE TABLE LIKE.
Se il DDL originale non è disponibile, è possibile utilizzare CREATE TABLE LIKE per ricreare la tabella originale. La nuova tabella eredita la codifica, la chiave di distribuzione, la chiave di ordinamento e gli attributi non null della tabella padre. La nuova tabella non eredita la chiave primaria e gli attributi di chiave esterna della tabella padre, ma è possibile aggiungerli utilizzando [ALTER TABLE](r_ALTER_TABLE.md).
+ Crea una tabella temporanea e tronca la tabella originale.
Se è necessario mantenere gli attributi della chiave primaria e della chiave esterna della tabella principale. Se la tabella principale ha dipendenze, puoi usare CREATE TABLE ... AS (CTAS) per creare una tabella temporanea. Quindi troncare la tabella originale e popolarla dalla tabella temporanea.
L'utilizzo di una tabella temporanea migliora le prestazioni in modo significativo rispetto all'utilizzo di una tabella permanente, ma c'è il rischio di perdere dati. La tabella temporanea viene automaticamente eliminata alla fine della sessione in cui è stata creata. TRUNCATE viene sottoposto immediatamente al commit, anche se si trova all'interno di un blocco di transazione. Se TRUNCATE ha esito positivo ma la sessione termina prima del completamento del comando INSERT successivo, i dati vengono persi. Se la perdita di dati non è accettabile, utilizza una tabella permanente.
Dopo aver creato una copia di una tabella, potrebbe essere necessario concedere l'accesso alla nuova tabella. È possibile utilizzare [GRANT](r_GRANT.md) per definire i privilegi di accesso. Per visualizzare e concedere tutti i privilegi di accesso di una tabella, devi avere uno dei seguenti ruoli:
+ Un utente con privilegi avanzati.
+ Il proprietario della tabella che si desidera copiare.
+ Un utente con il privilegio ACCESS SYSTEM TABLE per visualizzare i privilegi della tabella e con il privilegio di concessione per tutte le autorizzazioni pertinenti.
Inoltre, potrebbe essere necessario concedere l'autorizzazione all'utilizzo dello schema in cui si trova la copia completa. È necessario concedere l'autorizzazione all'utilizzo se lo schema della copia completa è diverso dallo schema della tabella originale e inoltre non è lo schema `public`. Per visualizzare e concedere tutti i privilegi di utilizzo, devi avere uno dei seguenti ruoli:
+ Un utente con privilegi avanzati.
+ Un utente che può concedere l'autorizzazione USAGE per lo schema della copia completa.
**Per eseguire una copia completa utilizzando la tabella con DDL originale**
1. (Facoltativo) Ricreare la tabella DDL eseguendo uno script chiamato `v_generate_tbl_ddl`.
1. Creare una copia della tabella utilizzando l'originale CREATE TABLE DDL.
1. Utilizzare un'istruzione INSERT INTO ... SELECT per popolare la copia con i dati della tabella originale.
1. Verifica le autorizzazioni concesse nella tabella precedente. Puoi visualizzare queste autorizzazioni nella vista di sistema SVV\$1RELATION\$1PRIVILEGES.
1. Se necessario, concedi le autorizzazioni della tabella precedente alla nuova tabella.
1. Concedi l'autorizzazione all'utilizzo a tutti i gruppi e utenti con privilegi nella tabella originale. Questo passaggio non è necessario se la tabella di copia completa è nello schema `public` o nello stesso schema della tabella originale.
1. Rilasciare la tabella originale.
1. Utilizzare un'istruzione ALTER TABLE per assegnare un nuovo nome alla copia con il nome della tabella originale.
L'esempio seguente esegue una copia completa sulla tabella SAMPLE utilizzando un duplicato di SAMPLE denominato sample\$1copy.
```
--Create a copy of the original table in the sample_namespace namespace using the original CREATE TABLE DDL.
create table sample_namespace.sample_copy ( … );
--Populate the copy with data from the original table in the public namespace.
insert into sample_namespace.sample_copy (select * from public.sample);
--Check SVV_RELATION_PRIVILEGES for the original table's privileges.
select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type;
--Grant the original table's privileges to the copy table.
grant DELETE on table sample_namespace.sample_copy to group group1;
grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2;
grant SELECT on table sample_namespace.sample_copy to user1;
grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2;
--Grant usage permission to every group and user that has privileges in the original table.
grant USAGE on schema sample_namespace to group group1, group group2, user1, user2;
--Drop the original table.
drop table public.sample;
--Rename the copy table to match the original table's name.
alter table sample_namespace.sample_copy rename to sample;
```
**Per eseguire una copia completa utilizzando CREATE TABLE LIKE**
1. Creare un nuovo tabella utilizzando CREATE TABLE LIKE.
1. Utilizzare un'istruzione INSERT INTO ... SELECT per copiare le righe dalla tabella attuale nella nuova tabella.
1. Verifica le autorizzazioni concesse nella tabella precedente. Puoi visualizzare queste autorizzazioni nella vista di sistema SVV\$1RELATION\$1PRIVILEGES.
1. Se necessario, concedi le autorizzazioni della tabella precedente alla nuova tabella.
1. Concedi l'autorizzazione all'utilizzo a tutti i gruppi e utenti con privilegi nella tabella originale. Questo passaggio non è necessario se la tabella di copia completa è nello schema `public` o nello stesso schema della tabella originale.
1. Rilasciare la tabella attuale.
1. Utilizzare un'istruzione ALTER TABLE per assegnare un nuovo nome alla nuova tabella con il nome della tabella originale.
L'esempio seguente esegue una copia completa sulla tabella SAMPLE utilizzando CREATE TABLE LIKE.
```
--Create a copy of the original table in the sample_namespace namespace using CREATE TABLE LIKE.
create table sameple_namespace.sample_copy (like public.sample);
--Populate the copy with data from the original table.
insert into sample_namespace.sample_copy (select * from public.sample);
--Check SVV_RELATION_PRIVILEGES for the original table's privileges.
select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type;
--Grant the original table's privileges to the copy table.
grant DELETE on table sample_namespace.sample_copy to group group1;
grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2;
grant SELECT on table sample_namespace.sample_copy to user1;
grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2;
--Grant usage permission to every group and user that has privileges in the original table.
grant USAGE on schema sample_namespace to group group1, group group2, user1, user2;
--Drop the original table.
drop table public.sample;
--Rename the copy table to match the original table's name.
alter table sample_namespace.sample_copy rename to sample;
```
**Per eseguire una copia completa tramite la creazione di una tabella temporanea e il troncamento della tabella originale**
1. Utilizzare CREATE TABLE AS per creare una tabella temporanea con le righe della tabella originale.
1. Troncare la tabella attuale.
1. Utilizzare un'istruzione INSERT INTO ... SELECT per copiare le righe dalla tabella temporanea nella tabella originale.
1. Rilasciare la tabella temporanea.
L'esempio seguente esegue una copia completa sulla tabella SALES tramite la creazione di una tabella temporanea e il troncamento della tabella originale. Poiché la tabella originale resta, non è necessario concedere autorizzazioni alla tabella di copia.
```
--Create a temp table copy using CREATE TABLE AS.
create temp table salestemp as select * from sales;
--Truncate the original table.
truncate sales;
--Copy the rows from the temporary table to the original table.
insert into sales (select * from salestemp);
--Drop the temporary table.
drop table salestemp;
```
# Analisi delle tabelle
L'operazione ANALYZE aggiorna i metadati statistici utilizzati dal pianificatore di query per scegliere i piani ottimali.
Nella maggior parte dei casi, non è necessario eseguire esplicitamente il comando ANALYZE. Amazon Redshift monitora le modifiche al carico di lavoro e aggiorna automaticamente le statistiche in background. Inoltre, il comando COPY esegue automaticamente un'analisi quando carica i dati in una tabella vuota.
Per analizzare in modo esplicito una tabella o l'intero database, esegui il comando [ANALYZE](r_ANALYZE.md).
## Analisi automatica
Amazon Redshift monitora ininterrottamente il database ed esegue automaticamente le operazioni di analisi in background. Per ridurre l'impatto sulle prestazioni del sistema, l'analisi automatica viene eseguita quando i carichi di lavoro sono più leggeri.
L'analisi automatica è abilitata per impostazione predefinita. Per disattivare l'analisi automatica, imposta il parametro `auto_analyze` su **false** modificando il gruppo di parametri del cluster.
Per ridurre il tempo di elaborazione e migliorare le prestazioni generali del sistema, Amazon Redshift ignora l'analisi automatica per qualsiasi tabella che abbia una percentuale di modifiche limitata.
Un'operazione di analisi salta le tabelle che contengono up-to-date statistiche. Se esegui ANALYZE nel flusso di lavoro ETL (Extract, Transform and Load, estrazione, trasformazione e caricamento), l'analisi automatica ignora le tabelle con statistiche aggiornate. Analogamente, un comando ANALYZE esplicito ignora le tabelle se l'analisi automatica ha aggiornato le statistiche della tabella.
## Analisi dei dati di nuove tabelle
Per impostazione predefinita, il comando COPY esegue un comando ANALYZE dopo aver caricato i dati in una tabella vuota. Puoi forzare un comando ANALYZE indipendentemente dal fatto che una tabella sia vuota impostando STATUPDATE ON. Se specifichi STATUPDATE OFF, ANALYZE non viene eseguito. Solo il proprietario della tabella o un utente con privilegi avanzati può eseguire il comando ANALYZE o eseguire il comando COPY con STATUPDATE impostata su ON.
Amazon Redshift analizza anche le nuove tabelle create con i seguenti comandi:
+ CREATE TABLE AS (CTAS)
+ CREATE TEMP TABLE AS
+ SELECT INTO
Auando si esegue una query su una nuova tabella che non è stata analizzata dopo il caricamento iniziale dei dati, Amazon Redshift restituisce un messaggio di avviso. Non vengono visualizzati avvisi quando esegui una query su una tabella dopo un successivo aggiornamento o caricamento. Lo stesso messaggio di avviso viene restituito quando esegui il comando EXPLAIN su una query che fa riferimento a tabelle non analizzate.
Se l'aggiunta di dati a una tabella non vuota modifica significativamente le dimensioni della tabella, puoi aggiornare le statistiche in modo esplicito. Per farlo, esegui il comando ANALYZE o l'opzione STATUPDATE ON con il comando COPY. Per visualizzare i dettagli sul numero di righe che sono state inserite o eliminate dall'ultimo ANALYZE, esegui una query sulla tabella del catalogo di sistema [PG\$1STATISTIC\$1INDICATOR](r_PG_STATISTIC_INDICATOR.md).
Puoi specificare l'ambito del comando [ANALYZE](r_ANALYZE.md) su una delle opzioni seguenti:
+ L'intero database attuale
+ Una tabella singola
+ Una o più colonne specifiche in una singola tabella
+ Colonne che possono essere utilizzate come predicati nelle query
Il comando ANALYZE ottiene un campione di righe dalla tabella, esegue alcuni calcoli e salva le statistiche delle colonne risultanti. Per impostazione predefinita, Amazon Redshift esegue un passaggio di esempio per la colonna DISTKEY e un altro passaggio di esempio per tutte le altre colonne nella tabella. Se desideri generare statistiche per un sottoinsieme di colonne, è possibile specificare un elenco di colonne separate da virgola. Puoi eseguire ANALYZE con la clausola PREDICATE COLUMNS per ignorare le colonne non utilizzate come predicati.
Le operazioni di ANALYZE richiedono molte risorse, quindi eseguile solo su tabelle e colonne che richiedono effettivamente aggiornamenti delle statistiche. Non è necessario analizzare tutte le colonne in tutte le tabelle regolarmente o nella stessa pianificazione. Se i dati cambiano in modo sostanziale, analizza le colonne utilizzate frequentemente nel modo seguente:
+ Operazioni di raggruppamento e ordinamento
+ Join
+ Predicati di query
Per ridurre i tempi di elaborazione e migliorare le prestazioni generali del sistema, Amazon Redshift ignora ANALYZE per qualsiasi tabella che abbia una bassa percentuale di righe modificate, come determinato dal parametro [analyze\$1threshold\$1percent](r_analyze_threshold_percent.md). Per impostazione predefinita, la soglia di analisi è impostata su 10 percento. È possibile modificare la soglia di analisi per la sessione attuale eseguendo un comando [SET](r_SET.md).
Le colonne che hanno meno probabilità di richiedere analisi frequenti sono quelle che rappresentano fatti e misure e tutti gli attributi correlati su cui non viene mai effettivamente eseguita una query, come le colonne VARCHAR di grandi dimensioni. Ad esempio, prendi in considerazione la tabella LISTING nel database TICKIT.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'listing';
column | type | encoding | distkey | sortkey
---------------+--------------------+----------+---------+---------
listid | integer | none | t | 1
sellerid | integer | none | f | 0
eventid | integer | mostly16 | f | 0
dateid | smallint | none | f | 0
numtickets | smallint | mostly8 | f | 0
priceperticket | numeric(8,2) | bytedict | f | 0
totalprice | numeric(8,2) | mostly32 | f | 0
listtime | timestamp with... | none | f | 0
```
Se questa tabella viene caricata ogni giorno con un numero elevato di nuovi record, la colonna LISTID, che viene spesso utilizzata nelle query come chiave di join, deve essere analizzata regolarmente. Se TOTALPRICE e LISTTIME sono i vincoli utilizzati frequentemente nelle query, è possibile analizzare tali colonne e la chiave di distribuzione in ogni giorno della settimana.
```
analyze listing(listid, totalprice, listtime);
```
Supponiamo che i venditori e gli eventi indicati nell'applicazione siano molto più statici e che la data IDs si riferisca a un insieme fisso di giorni che copre solo due o tre anni. i valori univoci per queste colonne non cambiano significativamente. Tuttavia, il numero di istanze di ogni valore univoco aumenterà costantemente.
Inoltre, prendi in considerazione il caso in cui venga eseguita raramente una query sulle misure NUMTICKETS e PRICEPERTICKET rispetto alla colonna TOTALPRICE. In questo caso, puoi eseguire il comando ANALYZE sull'intera tabella una volta ogni fine settimana per aggiornare le statistiche relative alle cinque colonne non analizzate giornalmente:
**Colonne di predicato**
Come valida alternativa alla specifica di un elenco di colonne, è possibile scegliere di analizzare solo le colonne che potrebbero essere utilizzate come predicati. Quando si esegue una query, tutte le colonne utilizzate in un join, una condizione del filtro o una clausola di raggruppamento vengono contrassegnate come colonne di predicato nel catalogo di sistema. Quando esegui ANALYZE con la clausola PREDICATE COLUMNS, l'operazione di analisi include solo le colonne che soddisfano i seguenti criteri:
+ La colonna è contrassegnata come una colonna di predicato.
+ La colonna è una chiave di distribuzione.
+ La colonna fa parte di una chiave di ordinamento.
Se nessuna delle colonne di una tabella è contrassegnata come predicato, ANALYZE include tutte le colonne, anche quando viene specificato PREDICATE COLUMNS. Se nessuna colonna è contrassegnata come colonne di predicato, potrebbe essere perché non è stata ancora eseguita una query sulla tabella.
È possibile scegliere di utilizzare PREDICATE COLUMNS quando il modello di query del carico di lavoro è relativamente stabile. Quando il modello di query è variabile, con colonne diverse utilizzate frequentemente come predicati, l'uso di PREDICATE COLUMNS potrebbe temporaneamente portare a statistiche obsolete. Le statistiche obsolete possono portare a piani di runtime delle query non ottimali e tempi di runtime lunghi. Tuttavia, la volta successiva che esegui ANALYZE utilizzando PREDICATE COLUMNS, vengono incluse le nuove colonne del predicato.
Per visualizzare i dettagli delle colonne dei predicati, utilizza il seguente codice SQL per creare una vista denominata PREDICATE\$1COLUMNS.
```
CREATE VIEW predicate_columns AS
WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name,
CASE
WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||')
WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
ELSE NULL::varchar
END AS pred_ts
FROM pg_statistic s
JOIN pg_class c ON c.oid = s.starelid
JOIN pg_namespace ns ON c.relnamespace = ns.oid
JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;
```
Presumi di eseguire la seguente query sulla tabella LISTING. Tieni presente che LISTID, LISTTIME ed EVENTID si utilizzano in un join, una condizione del filtro e una clausola di raggruppamento.
```
select s.buyerid,l.eventid, sum(l.totalprice)
from listing l
join sales s on l.listid = s.listid
where l.listtime > '2008-12-01'
group by l.eventid, s.buyerid;
```
Quando esegui una query sulla vista PREDICATE\$1COLUMNS, come illustrato nell'esempio seguente, puoi notare che LISTID, EVENTID e LISTTIME sono contrassegnati come colonne del predicato.
```
select * from predicate_columns
where table_name = 'listing';
```
```
schema_name | table_name | col_num | col_name | is_predicate | first_predicate_use | last_analyze
------------+------------+---------+----------------+--------------+---------------------+--------------------
public | listing | 1 | listid | true | 2017-05-05 19:27:59 | 2017-05-03 18:27:41
public | listing | 2 | sellerid | false | | 2017-05-03 18:27:41
public | listing | 3 | eventid | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41
public | listing | 4 | dateid | false | | 2017-05-03 18:27:41
public | listing | 5 | numtickets | false | | 2017-05-03 18:27:41
public | listing | 6 | priceperticket | false | | 2017-05-03 18:27:41
public | listing | 7 | totalprice | false | | 2017-05-03 18:27:41
public | listing | 8 | listtime | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41
```
Mantenere aggiornate le statistiche migliora le prestazioni delle query perché consente al pianificatore di query di scegliere i piani ottimali. Amazon Redshift aggiorna le statistiche automaticamente in background e consente di eseguire esplicitamente il comando ANALYZE. Se scegli di eseguire esplicitamente ANALYZE, procedi come descritto di seguito:
+ Esegui il comando ANALYZE prima di eseguire le query.
+ Esegui il comando ANALYZE sul database regolarmente alla fine di ogni normale ciclo di caricamento o aggiornamento.
+ Esegui il comando ANALYZE su qualsiasi nuova tabella che crei e su qualsiasi tabella o colonna esistente soggetta a modifiche significative.
+ Prendi in considerazione l'esecuzione di operazioni di ANALYZE su pianificazioni diverse per diversi tipi di tabelle e colonne, a seconda del loro utilizzo nelle query e della loro propensione al cambiamento.
+ Per risparmiare tempo e risorse cluster, utilizza la clausola PREDICATE COLUMNS quando esegui ANALYZE.
Non è necessario eseguire esplicitamente il comando ANALYZE dopo aver ripristinato un'istantanea in un cluster fornito o in uno spazio dei nomi serverless, né dopo aver ripreso un cluster con provisioning sospeso. Amazon Redshift conserva le informazioni della tabella di sistema in questi casi, rendendo superflui i comandi ANALYZE manuali. Amazon Redshift continuerà a eseguire operazioni di analisi automatiche in base alle esigenze.
Un'operazione di analisi ignora le tabelle che contengono statistiche. up-to-date Se esegui ANALYZE nel flusso di lavoro ETL (Extract, Transform and Load, estrazione, trasformazione e caricamento), l'analisi automatica ignora le tabelle con statistiche aggiornate. Analogamente, un comando ANALYZE esplicito ignora le tabelle se l'analisi automatica ha aggiornato le statistiche della tabella.
## Cronologia del comando ANALYZE
È utile sapere quando è stato eseguito l'ultima volta il comando ANALYZE su una tabella o un database. Quando viene eseguito un comando ANALYZE, Amazon Redshift esegue più query simili alla seguente:
```
padb_fetch_sample: select * from table_name
```
Esegui una query su STL\$1ANALYZE per visualizzare la cronologia delle operazioni di analisi. Se Amazon Redshift analizza una tabella con l'analisi automatica, la colonna `is_background` sarà impostata su `t` (true). Altrimenti, è impostata su `f` (false). L'esempio seguente collega STV\$1TBL\$1PERM per mostrare il nome della tabella e i dettagli di runtime.
```
select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, a.starttime, a.endtime
from stl_analyze a
join stv_tbl_perm t on t.id=a.table_id
where name = 'users'
order by starttime;
xid | name | status | rows | modified_rows | starttime | endtime
-------+-------+-----------------+-------+---------------+---------------------+--------------------
1582 | users | Full | 49990 | 49990 | 2016-09-22 22:02:23 | 2016-09-22 22:02:28
244287 | users | Full | 24992 | 74988 | 2016-10-04 22:50:58 | 2016-10-04 22:51:01
244712 | users | Full | 49984 | 24992 | 2016-10-04 22:56:07 | 2016-10-04 22:56:07
245071 | users | Skipped | 49984 | 0 | 2016-10-04 22:58:17 | 2016-10-04 22:58:17
245439 | users | Skipped | 49984 | 1982 | 2016-10-04 23:00:13 | 2016-10-04 23:00:13
(5 rows)
```
In alternativa, è possibile eseguire una query più complessa che restituisce tutte le istruzioni eseguite in ogni transazione completata che includeva un comando ANALYZE:
```
select xid, to_char(starttime, 'HH24:MM:SS.MS') as starttime,
datediff(sec,starttime,endtime ) as secs, substring(text, 1, 40)
from svl_statementtext
where sequence = 0
and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' )
order by xid desc, starttime;
xid | starttime | secs | substring
-----+--------------+------+------------------------------------------
1338 | 12:04:28.511 | 4 | Analyze date
1338 | 12:04:28.511 | 1 | padb_fetch_sample: select count(*) from
1338 | 12:04:29.443 | 2 | padb_fetch_sample: select * from date
1338 | 12:04:31.456 | 1 | padb_fetch_sample: select * from date
1337 | 12:04:24.388 | 1 | padb_fetch_sample: select count(*) from
1337 | 12:04:24.388 | 4 | Analyze sales
1337 | 12:04:25.322 | 2 | padb_fetch_sample: select * from sales
1337 | 12:04:27.363 | 1 | padb_fetch_sample: select * from sales
...
```
# Vacuum delle tabelle
Amazon Redshift può ordinare ed eseguire automaticamente un'operazione VACUUM DELETE su tabelle in background. Per ripulire le tabelle dopo un caricamento o una serie di aggiornamenti incrementali, è anche possibile eseguire il comando [VACUUM](r_VACUUM_command.md), sia sull'intero database, sia su singole tabelle.
**Nota**
Solo gli utenti con le autorizzazioni necessarie possono efficacemente eseguire l'operazione vacuum su una tabella. Se VACUUM viene eseguito senza le necessarie autorizzazioni di tabella, l'operazione viene completata ma non ha alcun effetto. Per l'elenco delle autorizzazioni di tabella valide per eseguire efficacemente VACUUM, consulta [VACUUM](r_VACUUM_command.md).
Per questo motivo, raccomandiamo di eseguire il VACUUM sulle specifiche tabelle secondo necessità. Consigliamo questo approccio anche perché l'operazione VACUUM dell'intero database è potenzialmente un'operazione costosa.
## Ordinamento automatico delle tabelle
Amazon Redshift ordina automaticamente i dati in background per mantenerli ordinati nella tabella rispetto alla chiave di ordinamento. Amazon Redshift tiene traccia delle query di scansione per determinare quali sezioni della tabella trarranno vantaggio dall'ordinamento. Amazon Redshift tiene inoltre traccia delle query di scansione provenienti da cluster con scalabilità simultanea. Per le architetture multicluster che utilizzano Amazon Redshift Data Sharing, Amazon Redshift tiene traccia anche delle query di scansione provenienti dal consumatore clusters/workgroups nella tua rete di dati, anche in diverse regioni. clusters/workgroups Le statistiche di scansione del cluster principale, dei cluster a scalabilità simultanea e dei cluster di consumatori vengono aggregate per determinare quali sezioni della tabella trarranno vantaggio dall'ordinamento.
In base al carico sul sistema, Amazon Redshift avvia automaticamente l'ordinamento. Questa operazione di ordinamento automatica riduce la necessità di eseguire il comando VACUUM per mantenere i dati ordinati secondo la chiave di ordinamento. Se sono necessari dati completamente ordinati in base alla chiave di ordinamento, ad esempio dopo un grande caricamento di dati, è comunque possibile eseguire manualmente il comando VACUUM. Per capire se la tabella trarrà benefici dall'esecuzione del comando VACUUM SORT, monitorare la colonna `vacuum_sort_benefit` in [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md).
Amazon Redshift tiene traccia delle query di scansione che utilizzano la chiave di ordinamento su ogni tabella. Amazon Redshift stima la percentuale massima di miglioramento nella scansione e nel filtraggio dei dati per ciascuna tabella (se la tabella è stata completamente ordinata). Tale stima è visibile nella colonna `vacuum_sort_benefit` in [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). È possibile usare questa colonna, insieme alla colonna `unsorted`, per determinare quali query possano beneficare dell'esecuzione manuale del comando VACUUM SORT su un tavolo La colonna `unsorted` riflette l'ordinamento fisico di una tabella. La colonna `vacuum_sort_benefit` specifica l'impatto dell'ordinamento di una tabella tramite l'esecuzione manuale del comando VACUUM SORT.
Considerare, ad esempio, lo schema seguente:
```
select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1;
```
```
table | unsorted | vacuum_sort_benefit
-------+----------+---------------------
sales | 85.71 | 5.00
event | 45.24 | 67.00
```
Per la tabella "vendite", sebbene la tabella sia fisicamente non ordinata per circa l'86%, l'impatto sulle prestazioni della query dovuto al fatto che la tabella non sia ordinata per l'86% è solo del 5%. Ciò potrebbe essere dovuto al fatto le query accedono solo a una piccola parte della tabella, o che pochissime query hanno dovuto accedere alla tabella. Per la tabella "evento", la tabella è fisicamente non ordinata per circa il 45%. Ma l'impatto sulle prestazioni della query del 67% indica che le query accedono a una porzione maggiore della tabella o che il numero di query che accedono alla tabella è elevato. La tabella "evento" può ottenere potenzialmente dei vantaggi dall'esecuzione del comando VACUUM SORT.
## Eliminazione vacuum automatica
Quando si esegue un'eliminazione, le righe vengono contrassegnate per l'eliminazione, ma non rimosse. Amazon Redshift esegue automaticamente un'operazione VACUUM DELETE in background in base al numero di righe eliminate nelle tabelle del database. Amazon Redshift pianificherà l'esecuzione di VACUUM DELETE durante i periodi di carico ridotto e sospenderà l'operazione durante i periodi di alto carico.
**Topics**
+ [Ordinamento automatico delle tabelle](#automatic-table-sort)
+ [Eliminazione vacuum automatica](#automatic-table-delete)
+ [Frequenza di VACUUM](#vacuum-frequency)
+ [Fase di ordinamento e fase di unione](#vacuum-stages)
+ [Soglia di vacuum](#vacuum-sort-threshold)
+ [Tipi di vacuum](#vacuum-types)
+ [Riduzione dei tempi di vacuum](vacuum-managing-vacuum-times.md)
## Frequenza di VACUUM
È opportuno eseguire l'operazione vacuum quando necessario per mantenere prestazioni di query coerenti. Prendi in considerazione questi fattori quando determini la frequenza con cui eseguire il comando VACUUM:
+ Esegui il comando VACUUM durante i periodi di tempo in cui prevedi un'attività minima sul cluster, ad esempio la sera o durante le finestre di amministrazione del database designate.
+ Esegui i comandi VACUUM al di fuori delle finestre di manutenzione. Per ulteriori informazioni, consulta [Pianificazione per le finestre di manutenzione](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html).
+ Un'ampia regione non ordinata comporta tempi di vacuum più lunghi. Se ritardi il vacuum, questo richiederà più tempo perché è necessario riorganizzare una quantità maggiore di dati.
+ VACUUM è un'operazione I/O intensiva, quindi più tempo impiega il completamento del vacuum, maggiore sarà l'impatto sulle query simultanee e su altre operazioni di database in esecuzione sul cluster.
+ VACUUM richiede più tempo per le tabelle che utilizzano l'ordinamento interleaved. Per valutare se è necessario riordinare le tabelle interlacciate, esegui una query sulla vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md).
## Fase di ordinamento e fase di unione
Amazon Redshift esegue un'operazione vacuum in due fasi: innanzitutto, ordina le righe nella regione non ordinata, quindi, se necessario, unisce le righe appena ordinate alla fine della tabella alle righe esistenti. Durante il vacuum di una tabella di grandi dimensioni, l'operazione di vacuum procede in una serie di passaggi costituiti da ordinamenti incrementali seguiti da unioni. Se l'operazione non riesce o se Amazon Redshift passa offline durante l'operazione vacuum, la tabella o il database parzialmente sottoposti a vacuum saranno in uno stato coerente, ma sarà necessario riavviare manualmente l'operazione vacuum. Gli ordinamenti incrementali vengono persi, ma non è necessario eseguire nuovamente il vacuum delle righe unite di cui è stato eseguito il commit prima dell'errore. Se la regione non ordinata è grande, l'operazione potrebbe richiedere molto tempo. Per ulteriori informazioni sulle fasi di ordinamento e unione, consultare [Ridurre il volume delle righe unite](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows).
Gli utenti possono accedere alle tabelle mentre ne viene eseguito il vacuum. È possibile eseguire query e scrivere operazioni mentre viene eseguito il vacuum di una tabella, ma quando il DML e il vacuum vengono eseguiti contemporaneamente, entrambe le operazioni potrebbero richiedere più tempo. Se si eseguono le istruzioni UPDATE e DELETE durante un vacuum, le prestazioni del sistema potrebbero essere ridotte. Le unioni incrementali bloccano temporaneamente le operazioni simultanee di UPDATE e DELETE e le operazioni di UPDATE e DELETE a loro volta bloccano temporaneamente le fasi di unione incrementale sulle tabelle interessate. Le operazioni di DDL, come ALTER TABLE, vengono bloccate fino al termine dell'operazione di vacuum con la tabella.
**Nota**
Vari modificatori per VACUUM controllano il modo in cui funziona. È possibile utilizzarli per personalizzare il funzionamento del vacuum in base alle esigenze attuali. Ad esempio, l'utilizzo di VACUUM RECLUSTER riduce l'operazione di vuoto non eseguendo un'operazione di fusione completa. Per ulteriori informazioni, consulta [VACUUM](r_VACUUM_command.md).
## Soglia di vacuum
Per impostazione predefinita, il comando VACUUM ignora la fase di ordinamento per ogni tabella dove più del 95% delle righe della tabella sono già ordinate. Ignorare la fase di ordinamento può migliorare significativamente le prestazioni di VACUUM. Per modificare la soglia di ordinamento predefinita per una singola tabella, includi il nome della tabella e il parametro TO *threshold* PERCENT quando esegui il comando VACUUM.
## Tipi di vacuum
Per ulteriori informazioni sui diversi tipi di vacuum, consultare [VACUUM](r_VACUUM_command.md).
# Riduzione dei tempi di vacuum
Amazon Redshift riordina automaticamente i dati ed esegue VACUUM DELETE in background. Ciò riduce la necessità di eseguire il comando VACUUM. Il vacuum è un processo potenzialmente dispendioso in termini di tempo. A seconda della natura dei dati, consigliamo di seguire le pratiche seguenti per ridurre al minimo i tempi di vacuum.
**Topics**
+ [Decidere sulla reindicizzazione](#r_vacuum-decide-whether-to-reindex)
+ [Ridurre le dimensioni della Regione non ordinata](#r_vacuum_diskspacereqs)
+ [Ridurre il volume delle righe unite](#vacuum-managing-volume-of-unmerged-rows)
+ [Caricare i dati nell’ordine delle chiavi di ordinamento](#vacuum-load-in-sort-key-order)
+ [Utilizzare le tabelle delle serie temporali per ridurre i dati archiviati](#vacuum-time-series-tables)
## Decidere sulla reindicizzazione
Spesso è possibile migliorare in modo significativo le prestazioni delle query utilizzando uno stile di ordinamento interleaved, ma le prestazioni nel tempo potrebbero peggiorare se la distribuzione dei valori nelle colonne delle chiavi di ordinamento cambia.
Quando inizialmente si carica una tabella interlacciata vuota utilizzando COPY o CREATE TABLE AS, Amazon Redshift crea automaticamente l'indice interlacciato. Se inizialmente carichi una tabella interleaved utilizzando INSERT, è necessario eseguire VACUUM REINDEX in seguito per inizializzare l'indice interleaved.
Nel corso del tempo, quando aggiungi righe con nuovi valori di chiave di ordinamento, le prestazioni potrebbero peggiorare se la distribuzione dei valori nelle colonne della chiave di ordinamento cambia. Se le nuove righe rientrano principalmente nell'intervallo dei valori delle chiavi di ordinamento esistenti, non è necessario reindicizzare. Esegui VACUUM SORT ONLY o VACUUM FULL per ripristinare l'ordinamento.
Il motore di query è in grado di utilizzare l'ordinamento per selezionare in modo efficiente i blocchi di dati che devono essere sottoposti a scansione per elaborare una query. Per un ordinamento interlacciato, Amazon Redshift analizza i valori della colonna chiave di ordinamento per determinare l'ordinamento ottimale. Se la distribuzione dei valori delle chiavi cambia o si differenzia, quando vengono aggiunte le righe, la strategia di ordinamento non sarà più ottimale e il vantaggio in termini di prestazioni dell'ordinamento diminuirà. Per analizzare nuovamente la distribuzione delle chiavi di ordinamento è possibile eseguire un VACUUM REINDEX. L'operazione di reindicizzazione richiede molto tempo, quindi per decidere se una tabella trarrà vantaggio da una reindicizzazione, esegui una query sulla vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md).
Ad esempio, la seguente query mostra i dettagli per le tabelle che utilizzano chiavi di ordinamento interleaved.
```
select tbl as tbl_id, stv_tbl_perm.name as table_name,
col, interleaved_skew, last_reindex
from svv_interleaved_columns, stv_tbl_perm
where svv_interleaved_columns.tbl = stv_tbl_perm.id
and interleaved_skew is not null;
tbl_id | table_name | col | interleaved_skew | last_reindex
--------+------------+-----+------------------+--------------------
100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45
100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45
100072 | part | 0 | 1.65 | 2015-04-22 22:05:45
100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45
(4 rows)
```
Il valore per `interleaved_skew` è un rapporto che indica la quantità di differenza. Il valore 1 indica nessuna differenza. Se la differenza è maggiore di 1,4, un VACUUM REINDEX di solito migliora le prestazioni a meno che la differenza non riguardi il set sottostante.
È possibile utilizzare il valore della data `last_reindex` per determinare quanto tempo è passato dall'ultima reindicizzazione.
## Ridurre le dimensioni della Regione non ordinata
La regione non ordinata aumenta quando carichi grandi quantità di nuovi dati in tabelle che contengono già dati o quando non esegui il vacuum delle tabelle come parte delle operazioni di manutenzione ordinaria. Per evitare operazioni di vacuum a lunga durata, utilizza le seguenti pratiche:
+ Esegui le operazioni di vacuum su una pianificazione regolare.
Se carichi le tabelle in piccoli incrementi (come gli aggiornamenti giornalieri che rappresentano una piccola percentuale del numero totale di righe nella tabella), eseguire regolarmente VACUUM contribuirà a garantire che le singole operazioni di vacuum siano rapide.
+ Esegui prima il carico maggiore.
Se è necessario caricare una nuova tabella con più operazioni di COPY, esegui prima il carico più grande. Quando esegui un caricamento iniziale in una tabella nuova o troncata, tutti i dati vengono caricati direttamente nella regione ordinata, quindi non è richiesto il vacuum.
+ Tronca una tabella anziché eliminare tutte le righe.
L'eliminazione di righe da una tabella non recupera lo spazio occupato dalle righe finché non esegui un'operazione di vacuum; tuttavia, il troncamento di una tabella svuota la tabella e recupera lo spazio su disco, quindi non è richiesto il vacuum. In alternativa, rilascia la tabella e creala nuovamente.
+ Tronca o rilascia tabelle di test.
Se stai caricando un numero limitato di righe in una tabella a scopo di test, non eliminare le righe al termine dell'operazione. Tronca, invece, la tabella e ricarica quelle righe come parte della successiva operazione di caricamento di produzione.
+ Esegui una copia completa.
Se una tabella che utilizza una tabella di chiavi di ordinamento composta presenta un'ampia regione non ordinata, una copia completa risulta molto più veloce di un vacuum. Una copia completa ricrea e ripopola una tabella tramite inserimento di massa, che ordina di nuovo automaticamente la tabella. Se una tabella ha una regione ampia e non ordinata, una copia completa è molto più veloce di un vacuum. Lo svantaggio è che non è possibile effettuare aggiornamenti simultanei durante un'operazione di copia completa, possibile invece durante un vacuum. Per ulteriori informazioni, consulta [Best practice di Amazon Redshift per la progettazione di query](c_designing-queries-best-practices.md).
## Ridurre il volume delle righe unite
Se un'operazione di vacuum deve unire nuove righe nella regione ordinata di una tabella, il tempo richiesto per un vacuum aumenterà man mano che le dimensioni della tabella aumenteranno. È possibile migliorare le prestazioni di vacuum riducendo il numero di righe che devono essere unite.
Prima di un'operazione vacuum, una tabella è composta da una regione ordinata nella parte superiore della tabella, seguita da una regione non ordinata, che aumenta ogni volta che vengono aggiunte o aggiornate delle righe. Quando un set di righe viene aggiunto da un'operazione di COPY, il nuovo set di righe viene ordinato sulla chiave di ordinamento quando viene aggiunto alla regione non ordinata nella parte inferiore della tabella. Le nuove righe sono ordinate all'interno dello stesso set, ma non all'interno della regione non ordinata.
Il diagramma seguente illustra la regione non ordinata dopo due successive operazioni di COPY, dove la chiave di ordinamento è CUSTID. Per semplicità, questo esempio mostra una chiave di ordinamento composta, ma gli stessi principi si applicano alle chiavi di ordinamento interleaved, tranne per il fatto che l'impatto della regione non ordinata è maggiore per le tabelle interleaved.
![\[Una tabella non ordinata contenente i record di due operazioni COPY.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/vacuum-unsorted-region.png)
Un vacuum ripristina l'ordinamento della tabella in due fasi:
1. Ordina la regione non ordinata in una regione appena ordinata.
La prima fase è relativamente economica, poiché viene riscritta solo la regione non ordinata. Se l'intervallo dei valori delle chiavi di ordinamento della regione appena ordinata è superiore all'intervallo esistente, solo le nuove righe devono essere riscritte e l'operazione vacuum è completa. Ad esempio, se la regione ordinata contiene valori di ID da 1 a 500 e le successive operazioni di COPY aggiungono valori chiave maggiori di 500, è necessario riscrivere solo la regione non ordinata.
1. Unisci la regione appena ordinata alla regione precedentemente ordinata.
Se le chiavi nella regione appena ordinata si sovrappongono alle chiavi nella regione ordinata, VACUUM deve unire le righe. Partendo dall'inizio della regione appena ordinata (con la chiave di ordinamento più bassa), il vacuum scrive le righe unite dalla regione ordinata in precedenza e la regione appena ordinata in una nuova serie di blocchi.
La misura in cui il nuovo intervallo di chiavi di ordinamento si sovrappone alle chiavi di ordinamento esistenti determina la misura in cui la regione precedentemente ordinata dovrà essere riscritta. Se le chiavi non ordinate sono distribuite nell'intero intervallo di ordinamento esistente, potrebbe essere necessario un vacuum per riscrivere le parti esistenti della tabella.
Il seguente diagramma mostra come un vacuum dovrebbe ordinare e unire righe che vengono aggiunte a una tabella in cui CUSTID è la chiave di ordinamento. Dato che ogni operazione di COPY aggiunge un nuovo set di righe con valori chiave che si sovrappongono alle chiavi esistenti, è necessario riscrivere quasi l'intera tabella. Il diagramma mostra una singola operazione di ordinamento e unione, ma in pratica, un'ampia operazione di vacuum consiste in una serie di fasi incrementali di ordinamento e unione.
![\[Un’operazione VACUUM per la tabella di esempio in due fasi. Prima vengono ordinate le nuove righe, che vengono quindi unite a quelle esistenti.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png)
Se l'intervallo di chiavi di ordinamento in un set di nuove righe si sovrappone all'intervallo di chiavi esistenti, il costo della fase di unione continua ad aumentare in proporzione alle dimensioni della tabella man mano che queste aumentano, mentre il costo della fase di ordinamento rimane proporzionale alla dimensione della regione non ordinata. In tal caso, il costo della fase di unione eclissa il costo della fase di ordinamento, come mostra il diagramma seguente.
![\[Diagramma che mostra come la fase di unione diventi più costosa quando le nuove righe hanno chiavi di ordinamento sovrapposte a righe esistenti.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/vacuum-example-merge-region-grows.png)
Per determinare quale proporzione di una tabella è stata rimossa, esegui una query su SVV\$1VACUUM\$1SUMMARY al termine dell'operazione di vacuum. La seguente query mostra l'effetto di sei successive operazioni di vacuum man mano che CUSTSALES aumentava nel tempo.
```
select * from svv_vacuum_summary
where table_name = 'custsales';
table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_
| | partitions | increments | time | delta | delta | delta | partitions
-----------+------+------------+------------+------------+-------+------------+---------+---------------
custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47
custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47
custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47
custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47
custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47
custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47
(6 rows)
```
La colonna merge\$1increments fornisce un'indicazione della quantità di dati che è stata unita per ciascuna operazione di vacuum. Se il numero di incrementi di unione in operazioni vacuum consecutive aumenta in proporzione alla crescita delle dimensioni della tabella, ciò indica che ogni operazione vacuum sta unendo nuovamente un numero crescente di righe nella tabella, poiché le regioni esistenti e appena ordinate si sovrappongono.
## Caricare i dati nell’ordine delle chiavi di ordinamento
Se carichi i dati nell'ordine delle chiavi di ordinamento utilizzando un comando COPY, è possibile ridurre o anche eliminare la necessità di eseguire un'operazione vacuum.
COPY aggiunge automaticamente nuove righe alla regione ordinata della tabella quando sono vere tutte le seguenti condizioni:
+ La tabella utilizza una chiave di ordinamento composta con una sola colonna di ordinamento.
+ La colonna di ordinamento è NOT NULL.
+ La tabella è ordinata al 100% o vuota.
+ Tutte le nuove righe sono più alte nell'ordinamento rispetto alle righe esistenti, incluse le righe contrassegnate per l'eliminazione. In questo caso, Amazon Redshift utilizza i primi otto byte della chiave di ordinamento per determinare l'ordinamento.
+ Il comando COPY non attiva determinate ottimizzazioni del carico. Quando si caricano grandi volumi di dati, Amazon Redshift può ottimizzare le prestazioni creando nuove partizioni ordinate anziché aggiungere righe alla regione ordinata della tabella.
Ad esempio, supponiamo di disporre di una tabella che registra gli eventi dei clienti utilizzando un ID cliente e l'ora. Se ordini in base all'ID cliente, è probabile che l'intervallo di chiavi di ordinamento delle nuove righe aggiunte da carichi incrementali si sovrapponga all'intervallo esistente, come illustrato nell'esempio precedente, portando a una costosa operazione di vacuum.
Se imposti la chiave di ordinamento su una colonna timestamp, le nuove righe verranno aggiunte in ordine nella parte inferiore della tabella, come illustrato nel diagramma seguente, riducendo o addirittura eliminando la necessità di eseguire un'operazione vacuum.
![\[Una tabella che utilizza una colonna timestamp come chiave di ordinamento per ottenere nuovi record che non devono essere ordinati.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png)
## Utilizzare le tabelle delle serie temporali per ridurre i dati archiviati
Se conservi i dati per un periodo di tempo continuo, utilizza una serie di tabelle, come illustrato nel diagramma seguente.
![\[Cinque tabelle con i dati relativi a cinque trimestri. La tabella meno recente viene eliminata per mantenere un periodo di tempo continuo.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png)
Crea una nuova tabella ogni volta che aggiungi un set di dati, quindi elimina la tabella più vecchia della serie. Ottieni un doppio vantaggio:
+ Eviti il costo aggiuntivo dell'eliminazione delle righe, poiché un'operazione di DROP TABLE è molto più efficiente di una di DELETE di massa.
+ Se le tabelle sono ordinate per timestamp, non è necessario il vacuum. Se ogni tabella contiene dati per un mese, il vacuum dovrà al massimo riscrivere i dati di un mese, anche se le tabelle non sono ordinate per timestamp.
È possibile creare una vista UNION ALL per l'utilizzo segnalando query che nascondono il fatto che i dati sono archiviati in più tabelle. Se una query filtra la chiave di ordinamento, il pianificatore di query può ignorare in modo efficiente tutte le tabelle che non vengono utilizzate. Un UNION ALL può essere meno efficiente per altri tipi di query, pertanto è necessario valutare le prestazioni delle query nel contesto di tutte le query che utilizzano le tabelle.
# Gestione delle operazioni di scrittura simultanee
Alcune applicazioni richiedono non solo query e caricamento simultanei, ma anche la possibilità di scrivere simultaneamente su più tabelle o sulla stessa tabella. In questo contesto, *simultaneamente* significa una sovrapposizione non pianificata per l'esecuzione simultanea. Due transazioni sono considerate simultanee se la seconda inizia prima del primo commit. Le operazioni simultanee possono provenire da sessioni diverse controllate dallo stesso utente o da utenti diversi.
Amazon Redshift supporta questi tipi di applicazioni consentendo la lettura delle tabelle mentre vengono modificate o caricate in modo incrementale. Le query visualizzano semplicemente l'ultima versione di cui è stato eseguito il commit o la *snapshot* dei dati, invece di attendere che venga eseguito il commit della successiva versione. Se desideri che una determinata query attenda il commit da un'altra operazione di scrittura, è necessario pianificarla di conseguenza.
**Nota**
Amazon Redshift supporta un comportamento di *commit automatico* di default in cui viene eseguito singolarmente il commit di ogni comando SQL eseguito separatamente. Se si racchiude un set di comandi in un blocco di transazione (definito dalle istruzioni [BEGIN](r_BEGIN.md) e [END](r_END.md)), viene eseguito il commit del blocco come una transazione, quindi è possibile eseguirne il rollback se necessario. Eccezioni a questo comportamento sono i comandi TRUNCATE e VACUUM, che eseguono automaticamente il commit di tutte le modifiche in sospeso apportate nella transazione corrente.
Alcuni client SQL eseguono automaticamente i comandi BEGIN e COMMIT, pertanto il client controlla se un gruppo di istruzioni viene eseguito come transazione o se ogni singola istruzione viene eseguita come transazione propria. Controlla la documentazione per l'interfaccia che stai utilizzando. Ad esempio, quando si utilizza il driver JDBC di Amazon Redshift, un'istruzione JDBC `PreparedStatement` con una stringa di query che contiene più comandi SQL (separati da punto e virgola) esegue tutte le istruzioni come una singola transazione. Al contrario, se usi SQL Workbench/J e imposti AUTO COMMIT ON, se esegui più istruzioni, ogni istruzione viene eseguita come transazione a sé stante.
I seguenti argomenti descrivono alcuni concetti chiave e casi d'uso che riguardano transazioni, snapshot del database, aggiornamenti e comportamento simultaneo.
**Topics**
+ [Livelli di isolamento in Amazon Redshift](c_serial_isolation.md)
+ [Scrittura e read/write operazioni](c_write_readwrite.md)
+ [Esempi di scrittura simultanea](r_Serializable_isolation_example.md)
+ [Risoluzione degli errori di isolamento serializzabile](c_serial_isolation-serializable-isolation-troubleshooting.md)
# Livelli di isolamento in Amazon Redshift
Le operazioni di scrittura simultanee sono supportate in Amazon Redshift in modo protettivo utilizzando i blocchi di scrittura sulle tabelle e il principio di *isolamento serializzabile*. L'isolamento serializzabile mantiene l'illusione che una transazione in esecuzione su una tabella sia l'unica transazione in esecuzione su quella tabella.
I database Amazon Redshift supportano le operazioni di scrittura simultanee facendo in modo che ogni operazione utilizzi l’ultima versione con commit, o snapshot, dei propri dati all’inizio della transazione. Una snapshot del database viene creata all'interno di una transazione alla prima occorrenza della maggior parte delle istruzioni SELECT, dei comandi DML come COPY, DELETE, INSERT, UPDATE e TRUNCATE e dei seguenti comandi DDL:
+ ALTER TABLE (per aggiungere o eliminare colonne)
+ CREATE TABLE
+ DROP TABLE
+ TRUNCATE TABLE
Nessun’altra transazione è in grado di modificare questo snapshot, il che significa che le transazioni sono isolate l’una dall’altra. In altre parole le transazioni simultanee sono invisibili l’una all’altra e non possono rilevare le modifiche reciproche.
Qualsiasi esecuzione simultanea di transazioni deve produrre gli stessi risultati dell’esecuzione seriale di tali transazioni. Se nessuna esecuzione seriale di tali transazioni produce gli stessi risultati, la transazione che esegue un'istruzione che potrebbe interrompere la serializzabilità viene arrestata e ne viene eseguito il rollback.
Ad esempio, supponiamo che un utente tenti di eseguire due transazioni simultanee, T1 e T2. L’esecuzione di T1 e T2 deve produrre gli stessi risultati di almeno uno degli scenari seguenti:
+ T1 e T2 vengono eseguite in serie in questo ordine
+ T2 e T1 vengono eseguite in serie in questo ordine
I livelli di isolamento in Amazon Redshift prevengono i seguenti problemi:
+ Letture non corrette: una lettura errata si verifica quando una transazione legge dati che non sono ancora stati sottoposti a commit. Ad esempio, supponiamo che la transazione 1 aggiorni una riga. La transazione 2 legge la riga aggiornata prima che T1 esegua il commit dell’aggiornamento. Se T1 esegue il rollback della modifica, T2 ha letto i dati in righe non sottoposte a commit che Amazon Redshift ora ritiene non siano mai esistite.
+ Letture non ripetibili: una lettura non ripetibile si verifica quando una singola transazione legge due volte la stessa riga, ma riceve dati diversi ogni volta. Ad esempio, supponiamo che la transazione 1 legga una riga. La transazione 2 aggiorna o elimina tale riga ed esegue il commit dell’aggiornamento o dell’eliminazione. Se T1 rilegge la riga, recupera valori di riga diversi o scopre che la riga è stata eliminata.
+ Fantasmi: un fantasma è una riga che corrisponde ai criteri di ricerca ma inizialmente non viene visualizzata. Ad esempio, supponiamo che la transazione 1 legga un insieme di righe che soddisfano i criteri di ricerca. La transazione 2 genera una nuova riga in un’istruzione UPDATE o INSERT che corrisponde ai criteri di ricerca per T1. Se T1 esegue nuovamente l’istruzione di ricerca, ottiene un set di righe diverso.
## Isolamento SNAPSHOT e SERIALIZABLE
In Amazon Redshift gli isolamenti SERIALIZABLE e SNAPSHOT sono due livelli di isolamento serializzabili.
L’isolamento SNAPSHOT è il livello di isolamento predefinito per la creazione di cluster con provisioning e gruppi di lavoro serverless e consente di elaborare volumi di dati più grandi rispetto all’isolamento SERIALIZABLE in meno tempo.
L’isolamento SERIALIZABLE richiede più tempo, ma implementa vincoli più severi per le transazioni simultanee. Questo livello di isolamento previene problemi come le anomalie di inclinazione della scrittura perché consente il commit di una sola transazione e annulla tutte le altre transazioni simultanee con un errore di violazione dell’isolamento serializzabile.
Di seguito è riportato un esempio cronologico di come verrebbero gestite due operazioni di scrittura simultanee quando utilizzi l’isolamento SNAPSHOT. È consentito eseguire il commit dell’istruzione UPDATE di ogni utente in quanto non crea conflitti se tenti di aggiornare le stesse righe.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_serial_isolation.html)
Se lo stesso scenario viene eseguito utilizzando l'isolamento serializzabile, Amazon Redshift termina l'utente 2 a causa di una violazione della serializzazione e restituisce un errore `1023`. Per ulteriori informazioni, consulta [Risoluzione degli errori di isolamento serializzabile](c_serial_isolation-serializable-isolation-troubleshooting.md). In questo caso, solo l'utente 1 può eseguire correttamente il commit.
## Considerazioni
Quando utilizzi livelli di isolamento in Amazon Redshift, considera quanto segue:
+ Esegui query sulla vista del catalogo STV\$1DB\$1ISOLATION\$1LEVEL per visualizzare il livello di isolamento utilizzato dal database. Per ulteriori informazioni, consulta [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md).
+ Esegui query sulla vista PG\$1DATABASE\$1INFO per visualizzare quante transazioni simultanee sono supportate per il database. Per ulteriori informazioni, consulta [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md).
+ Le tabelle del catalogo di sistema (PG) e altre tabelle di sistema Amazon Redshift non sono bloccate in una transazione. Di conseguenza, le modifiche agli oggetti di database che derivano dalle operazioni di DDL e TRUNCATE sono visibili al commit in qualsiasi transazione simultanea.
Ad esempio, supponiamo che la tabella A esiste nel database quando iniziano due transazioni simultanee, T1 e T2. Supponiamo che T2 restituisca un elenco di tabelle selezionandole dalla tabella catalogo PG\$1TABLES. Quindi T1 rilascia la tabella A ed esegue il commit, quindi T2 elenca nuovamente le tabelle. La tabella A non è più elencata. Se T2 prova a eseguire una query sulla tabella rilasciata, Amazon Redshift restituisce un errore di relazione inesistente. La query di catalogo che restituisce l'elenco di tabelle a T2 o verifica che la tabella A esista non è soggetta alle stesse regole di isolamento delle operazioni sulle tabelle utente.
Le transazioni per gli aggiornamenti a queste tabelle vengono eseguite in modalità di isolamento con lettura sottoposta al commit.
+ Le tabelle del catalogo dei prefissi PG non supportano l’isolamento SNAPSHOT.
# Scrittura e read/write operazioni
È possibile gestire il comportamento specifico delle operazioni simultanee di scrittura decidendo quando e come eseguire diversi tipi di comandi. I seguenti comandi sono rilevanti a tal riguardo:
+ Comandi COPY, che eseguono caricamenti (iniziali o incrementali)
+ Comandi INSERT, che aggiungono una o più righe alla volta
+ Comandi UPDATE, che modificano le righe esistenti
+ Comandi DELETE, che rimuovono le righe esistenti
Le operazioni COPY e UPDATE sono operazioni di scrittura pura. Le operazioni DELETE e UPDATE sono read/write operazioni (per eliminare o aggiornare le righe, devono prima essere lette). I risultati delle operazioni di scrittura simultanee dipendono dai comandi specifici che vengono eseguiti simultaneamente.
Le operazioni di UPDATE e DELETE si comportano in modo diverso perché si basano su una tabella iniziale prima di eseguire qualsiasi scrittura. Dato che le transazioni simultanee sono invisibili l'una all'altra, entrambe UPDATEs DELETEs devono leggere un'istantanea dei dati dell'ultimo commit. Quando il primo UPDATE o DELETE rilascia il suo blocco, il secondo UPDATE o DELETE deve determinare se i dati con cui lavorerà sono potenzialmente obsoleti. Non saranno obsoleti, perché la seconda transazione non ottiene la sua snapshot di dati fino a quando la prima transazione non ha rilasciato il blocco.
## Situazione potenziale di deadlock per le transazioni di scrittura simultanee che coinvolgono più tabelle
Quando le transazioni coinvolgono aggiornamenti di più di una tabella, esiste sempre la possibilità di eseguire simultaneamente le transazioni in deadlock quando entrambe cercano di scrivere nello stesso set di tabelle. Una transazione rilascia tutti i blocchi della tabella in una volta sola quando esegue il commit o il rollback. Non rilascia i blocchi uno alla volta.
Ad esempio, supponiamo che le transazioni simultanee, T1 e T2 inizino circa nello stesso momento. Se T1 inizia a scrivere nella tabella A e T2 inizia a scrivere nella tabella B, entrambe le transazioni possono procedere senza conflitti. Tuttavia, se T1 inizia a scrivere nella tabella A e ha bisogno di iniziare a scrivere nella tabella B, non è in grado di procedere perché T2 mantiene ancora il blocco su B. Allo stesso modo, se T2 finisce di scrivere nella tabella B e deve iniziare a scrivere nella tabella A, non è in grado di procedere perché T1 mantiene ancora il blocco su A. Poiché nessuna transazione può rilasciare i blocchi finché tutte le operazioni di scrittura non vengono eseguite, l’altra transazione non può procedere. Per evitare questo tipo di deadlock, devi pianificare attentamente le operazioni di scrittura simultanee. Ad esempio, è necessario aggiornare sempre le tabelle nello stesso ordine nelle transazioni e, se si specificano i blocchi, bloccare le tabelle nello stesso ordine prima di eseguire qualsiasi operazione di DML.
## Potenziale situazione di deadlock per le transazioni di scrittura simultanee che coinvolgono una singola tabella
In un ambiente di isolamento degli snapshot, possono verificarsi dei deadlock quando esegui transazioni di scrittura simultanee nella stessa tabella. Il deadlock di isolamento degli snapshot si verifica quando le istruzioni INSERT o COPY simultanee condividono un blocco e procedono e un’altra istruzione deve eseguire un’operazione (UPDATE, DELETE, MERGE o DDL) che richiede un blocco esclusivo sulla stessa tabella.
Considera il seguente scenario:
Transazione 1 (T1):
```
INSERT/COPY INTO table_A;
```
Transazione 2 (T2):
```
INSERT/COPY INTO table_A;
table_A
```
Un deadlock può verificarsi quando più transazioni con le operazioni INSERT o COPY vengono eseguite simultaneamente nella stessa tabella con un blocco condiviso e una di queste transazioni segue l’operazione di scrittura pura con un’operazione che richiede un blocco esclusivo, come un’istruzione UPDATE, MERGE, DELETE o DDL.
Per evitare il deadlock in queste situazioni, è possibile separare le istruzioni che richiedono un blocco esclusivo (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEistruzioni sulla stessa tabella) e includere la logica di ripetizione nelle applicazioni per aggirare potenziali situazioni di stallo.
# Esempi di scrittura simultanea
I seguenti esempi di pseudo codice dimostrano come, quando vengono eseguite simultaneamente, le transazioni procedono o attendono.
## Esempi di scrittura simultanea con isolamento serializzabile
### Operazioni COPY simultanee nella stessa tabella con isolamento serializzabile
La transazione 1 copia le righe nella tabella LISTING:
```
begin;
copy listing from ...;
end;
```
La transazione 2 inizia simultaneamente in una sessione separata e prova a copiare più righe nella tabella LISTING. La transazione 2 deve attendere che la transazione 1 rilasci il blocco di scrittura sulla tabella LISTING, quindi può procedere.
```
begin;
[waits]
copy listing from ;
end;
```
Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando INSERT anziché un comando COPY.
### Operazioni DELETE simultanee nella stessa tabella con isolamento serializzabile
La transazione 1 elimina le righe da una tabella:
```
begin;
delete from listing where ...;
end;
```
La transazione 2 inizia simultaneamente e prova a eliminare le righe dalla stessa tabella. Avrà esito positivo perché attende il completamento della transazione 1 prima di provare eliminare le righe.
```
begin
[waits]
delete from listing where ;
end;
```
Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando UPDATE nella stessa tabella anziché un comando DELETE.
### Transazioni simultanee con una combinazione di operazioni di lettura e scrittura e isolamento serializzabile
In questo esempio, la transazione 1 elimina le righe dalla tabella USERS, ricarica la tabella, esegue una query su COUNT (\$1) e quindi ANALYZE prima di eseguire il commit:
```
begin;
delete one row from USERS table;
copy ;
select count(*) from users;
analyze ;
end;
```
Allo stesso tempo, inizia la transazione 2. Questa transazione prova a copiare righe aggiuntive nella tabella USERS, ad analizzare la tabella e quindi a eseguire la stessa query su COUNT (\$1) come la prima transazione:
```
begin;
[waits]
copy users from ...;
select count(*) from users;
analyze;
end;
```
La seconda transazione avrà esito positivo perché deve attendere il completamento della prima. La sua query su COUNT restituirà il conteggio in base al caricamento che ha completato.
## Esempi di scrittura simultanea con isolamento degli snapshot
### Operazioni simultanee di COPY nella stessa tabella con isolamento degli snapshot
La transazione 1 copia le righe nella tabella LISTING:
```
begin;
copy listing from ...;
end;
```
La transazione 2 inizia simultaneamente in una sessione separata e prova a copiare più righe nella tabella LISTING. La transazione 2 può procedere simultaneamente fino a quando una delle due transazioni non deve scrivere i dati nella tabella di destinazione `listing`, dopodiché vengono eseguite in sequenza.
```
begin;
//When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits.
copy listing from ...;
end;
```
Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando INSERT anziché un comando COPY.
### Operazioni DELETE simultanee nella stessa tabella con isolamento degli snapshot
Le operazioni DELETE o UPDATE simultanee nella stessa tabella con l’isolamento degli snapshot vengono eseguite allo stesso modo delle operazioni eseguite con l’isolamento serializzabile.
### Transazioni simultanee con una combinazione di operazioni di lettura e scrittura e l’isolamento degli snapshot
Le transazioni simultanee eseguite con combinazioni di operazioni con l’isolamento degli snapshot vengono eseguite allo stesso modo delle transazioni con combinazioni di operazioni eseguite con l’isolamento serializzabile.
# Risoluzione degli errori di isolamento serializzabile
## ERROR:1023 DETAIL: violazione di isolamento serializzabile su una tabella in Redshift
Quando Amazon Redshift rileva un errore di isolamento serializzabile, compare un messaggio di errore simile al seguente.
```
ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift
```
Per risolvere un errore di isolamento serializzabile, si possono tentare i seguenti metodi:
+ Riprovare la transazione annullata.
Amazon Redshift ha rilevato che un carico di lavoro simultaneo non è serializzabile. Suggerisce lacune nella logica dell'applicazione, che di solito possono essere risolte provando a eseguire di nuovo la transazione che ha riscontrato l'errore. Se il problema persiste, provare uno degli altri metodi.
+ Spostare al di fuori della transazione tutte le operazioni che non devono essere nella stessa transazione atomica.
Questo metodo si applica quando singole operazioni all'interno di due transazioni fanno riferimento reciprocamente in modo tale da influire sul risultato dell'altra transazione. Ad esempio, ciascuna delle seguenti due sessioni avvia una transazione.
```
Session1_Redshift=# begin;
```
```
Session2_Redshift=# begin;
```
Il risultato di un'istruzione SELECT in una delle transazioni potrebbe essere compromesso da un'istruzione INSERT nell'altra. In altre parole, si presuppone che le seguenti istruzioni vengano eseguite in serie, in qualunque ordine. In ogni caso, il risultato è che una delle istruzioni SELECT restituisce una riga in più rispetto all'esecuzione simultanea delle transazioni. Non esiste un ordine in cui le operazioni in serie possono produrre lo stesso risultato dell'esecuzione simultanea. Di conseguenza, l'ultima operazione eseguita genera un errore di isolamento serializzabile.
```
Session1_Redshift=# select * from tab1;
Session1_Redshift=# insert into tab2 values (1);
```
```
Session2_Redshift=# insert into tab1 values (1);
Session2_Redshift=# select * from tab2;
```
In molti casi il risultato delle istruzioni SELECT non è importante. In altre parole, l'atomicità delle operazioni nelle transazioni non è importante. In questi casi, occorre spostare le istruzioni SELECT al di fuori delle transazioni, come illustrato nei seguenti esempi.
```
Session1_Redshift=# begin;
Session1_Redshift=# insert into tab1 values (1)
Session1_Redshift=# end;
Session1_Redshift=# select * from tab2;
```
```
Session2_Redshift # select * from tab1;
Session2_Redshift=# begin;
Session2_Redshift=# insert into tab2 values (1)
Session2_Redshift=# end;
```
In questi esempi non ci sono riferimenti reciproci nelle transazioni. Le due istruzioni INSERT non si compromettono reciprocamente. In questi esempi c'è almeno un ordine in cui le transazioni possono essere eseguite in serie producendo lo stesso risultato dell'esecuzione simultanea. Ciò vuol dire che le transazioni sono serializzabili.
+ Forzare la serializzazione bloccando tutte le tabelle in ciascuna sessione.
Il comando [LOCK](r_LOCK.md) blocca le operazioni che possono generare errori di isolamento serializzabile. Quando utilizzi il comando LOCK, ricorda di fare quanto segue:
+ Bloccare tutte le tabelle interessate dalla transazione, incluse quelle interessate dalle istruzioni SELECT di sola lettura all'interno della transazione.
+ Bloccare le tabelle nello stesso ordine, indipendentemente da quello in cui vengono eseguite le operazioni.
+ Bloccare tutte le tabelle all'inizio delle transazione, prima di eseguire qualunque operazione.
+ Utilizzo dell'isolamento degli snapshot per le transazioni simultanee
Utilizza un comando ALTER DATABASE con isolamento degli snapshot. Per ulteriori informazioni sul parametro SNAPSHOT per ALTER DATABASE, consulta [Parameters](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters).
## ERROR:1018 DETAIL: la relazione non esiste
Quando le operazioni simultanee di Amazon Redshift vengono eseguite in sessioni diverse, viene visualizzato un messaggio di errore simile al seguente.
```
ERROR: 1018 DETAIL: Relation does not exist.
```
Le transazioni in Amazon Redshift seguono l'isolamento degli snapshot. Dopo l'inizio di una transazione, Amazon Redshift acquisisce uno snapshot del database. Per l'intero ciclo di vita della transazione, la transazione opera sullo stato del database come indicato nello snapshot. Se la transazione legge da una tabella che non esiste nello snapshot, genera il messaggio di errore 1018 mostrato in precedenza. Anche quando un'altra transazione simultanea crea una tabella dopo che la transazione ha acquisito lo snapshot, la transazione non può leggere dalla tabella appena creata.
Per risolvere questo errore di isolamento della serializzazione, è possibile provare a spostare l'inizio della transazione in un punto in cui si sa che la tabella esiste.
Se la tabella viene creata da un'altra transazione, questo punto è almeno dopo il commit della transazione. Inoltre, assicurarsi che non sia stata eseguita alcuna transazione simultanea che potrebbe aver eliminato la tabella.
```
session1 = # BEGIN;
session1 = # DROP TABLE A;
session1 = # COMMIT;
```
```
session2 = # BEGIN;
```
```
session3 = # BEGIN;
session3 = # CREATE TABLE A (id INT);
session3 = # COMMIT;
```
```
session2 = # SELECT * FROM A;
```
Di conseguenza, l'ultima operazione eseguita come operazione di lettura da session2 genera un errore di isolamento serializzabile. Questo errore si verifica quando session2 esegue uno snapshot e la tabella è già stata eliminata da una sessione di commit 1. In altre parole, anche se una session3 simultanea ha creato la tabella, session2 non vede la tabella perché non è nello snapshot.
Per risolvere questo errore, è possibile ordinare nuovamente le sessioni come segue.
```
session1 = # BEGIN;
session1 = # DROP TABLE A;
session1 = # COMMIT;
```
```
session3 = # BEGIN;
session3 = # CREATE TABLE A (id INT);
session3 = # COMMIT;
```
```
session2 = # BEGIN;
session2 = # SELECT * FROM A;
```
Ora, quando session2 effettua il suo snapshot, per session3 è già stato eseguito il commit e la tabella è nel database. Session2 può leggere dalla tabella senza alcun errore.
# Tutorial: Caricamento dei dati da Amazon S3
Questo tutorial guida attraverso l'intero processo di caricamento di dati nelle tabelle di database Amazon Redshift a partire dai file di dati in un bucket Amazon S3.
In questo tutorial, esegui quanto indicato di seguito:
+ Scarichi file di dati che utilizzano formati CSV, delimitati da caratteri e a larghezza fissa.
+ Creare un bucket Amazon S3 e quindi caricare i file di dati nel bucket.
+ Avviare un cluster Amazon Redshift e creare le tabelle di database.
+ Utilizzare i comandi COPY per caricare le tabelle dai file di dati su Amazon S3.
+ Risolvere gli errori di caricamento e modificare i comandi COPY per correggere gli errori.
## Prerequisiti
Sono necessari i seguenti prerequisiti:
+ Un AWS account per avviare un cluster Amazon Redshift e creare un bucket in Amazon S3.
+ AWS Le tue credenziali (ruolo IAM) per caricare i dati di test da Amazon S3. Se hai bisogno di un nuovo ruolo IAM, vai a [Creazione di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html).
+ Un client SQL, ad esempio l'editor di query della console Amazon Redshift.
Questo tutorial è stato concepito in modo da essere svolto indipendentemente dagli altri. Oltre a questo tutorial, consigliamo di seguire i tutorial seguenti per avere una migliore comprensione del modo in cui progettare e utilizzare database Amazon Redshift.
+ Il manuale [Guida alle operazioni di base di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) guiderà attraverso il processo di creazione di un cluster Amazon Redshift e nel caricamento di dati di esempio.
## Panoramica di
È possibile aggiungere dati alle tabelle Amazon Redshift utilizzando un comando INSERT o COPY. Alla scala e alla velocità di un data warehouse Amazon Redshift, il comando COPY risulta molto più veloce ed efficace dei comandi INSERT.
Il comando COPY utilizza l'architettura MPP (Massively Parallel Processing) di Amazon Redshift per leggere e caricare dati in parallelo da più origini dati. È possibile caricare i file di dati su Amazon S3, Amazon EMR o qualsiasi host remoto accessibile mediante una connessione Secure Shell (SSH). In alternativa, è possibile caricare direttamente da una tabella Amazon DynamoDB.
In questo tutorial, sarà utilizzato il comando COPY per caricare dati da Amazon S3. Molti dei principi presentati qui sono validi anche per il caricamento da altre origini dati.
Per ulteriori informazioni sull'utilizzo del comando COPY, consultare le seguenti risorse:
+ [Best practice di Amazon Redshift per il caricamento di dati](c_loading-data-best-practices.md)
+ [Caricamento di dati da Amazon EMR](loading-data-from-emr.md)
+ [Caricamento di dati da host remoti](loading-data-from-remote-hosts.md)
+ [Caricamento di dati da una tabella Amazon DynamoDB](t_Loading-data-from-dynamodb.md)
## Fase 1: creazione di un cluster
Se disponi già di un cluster che intendi utilizzare, puoi ignorare questa fase.
Per gli esercizi in questo tutorial, si utilizza un cluster a quattro nodi.
**Come creare un cluster**
1. Accedi a Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
Dal menu di navigazione, scegli **Pannello di controllo dei cluster con provisioning**.
**Importante**
Verifica di disporre delle autorizzazioni necessarie per eseguire le operazioni relative al cluster. Per informazioni sulla concessione delle autorizzazioni necessarie, consulta [Autorizzazione di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html) all'accesso ai servizi. AWS
1. In alto a destra, scegli la AWS regione in cui desideri creare il cluster. Ai fini del presente tutorial, selezionare **Stati Uniti occidentali (Oregon)**.
1. Dal menu di navigazione, scegliere **Clusters** (Cluster), quindi **Create cluster** (Crea cluster). Appare la pagina **Create cluster (Crea cluster)**.
1. Alla pagina **Creazione di un cluster** inserire i parametri per il cluster. Scegliere i tuoi valori per i parametri, eccetto modificare i seguenti valori:
+ Scegliere **dc2.large** per il tipo di nodo.
+ Scegliere **4** per **Numero di nodi**.
+ Nella sezione **Cluster permissions (Autorizzazioni cluster)**, scegli un ruolo IAM da **Available IAM roles (Ruoli IAM disponibili)**. Questo ruolo dovrebbe essere quello che creato in precedenza e che ha accesso ad Amazon S3. Quindi scegliere **Add IAM role (Aggiungi ruolo IAM)** per aggiungerlo all'elenco degli **Attached IAM roles (Ruoli IAM collegati)** del cluster.
1. Scegli **Crea cluster**.
Seguire la procedura riportata in [Guida alle operazioni di base di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) per connettersi al cluster da un client SQL e testare una connessione. Non è necessario mettere in pratica le altre fasi indicate nella Guida Rapida relativa alla creazione di tabelle, al caricamento di dati e all'esecuzione di query di esempio.
## Fase 2: download dei file di dati
In questa fase, scarichi un set di file di dati di esempio sul tuo computer. Nella fase successiva, i file verranno caricati in un bucket Amazon S3.
**Per scaricare i file di dati**
1. Scarica il file compresso: [LoadingDataSampleFiles.zip](samples/LoadingDataSampleFiles.zip).
1. Estrarre i file in una cartella sul computer.
1. Verificare che la cartella contenga i file seguenti.
```
customer-fw-manifest
customer-fw.tbl-000
customer-fw.tbl-000.bak
customer-fw.tbl-001
customer-fw.tbl-002
customer-fw.tbl-003
customer-fw.tbl-004
customer-fw.tbl-005
customer-fw.tbl-006
customer-fw.tbl-007
customer-fw.tbl.log
dwdate-tab.tbl-000
dwdate-tab.tbl-001
dwdate-tab.tbl-002
dwdate-tab.tbl-003
dwdate-tab.tbl-004
dwdate-tab.tbl-005
dwdate-tab.tbl-006
dwdate-tab.tbl-007
part-csv.tbl-000
part-csv.tbl-001
part-csv.tbl-002
part-csv.tbl-003
part-csv.tbl-004
part-csv.tbl-005
part-csv.tbl-006
part-csv.tbl-007
```
## Fase 3: Caricamento dei file in un bucket Amazon S3
In questa fase, viene creato un bucket Amazon S3 e quindi i file di dati vengono caricati nel bucket.
###
**Come caricare i file in un bucket Amazon S3**
1. Creare un bucket in Amazon S3.
Per ulteriori informazioni sulla creazione di un bucket, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
1. Accedi a Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Seleziona **Crea bucket**.
1. Scegli un Regione AWS.
Creare il bucket nella stessa regione del cluster. Se il cluster è nella regione Stati Uniti occidentali (Oregon), scegliere **Regione Stati Uniti occidentali (Oregon) (us-west-2)**.
1. Immetti un nome per il bucket nella casella **Nome bucket** della finestra di dialogo **Crea bucket**.
Il nome di bucket scelto deve essere univoco tra tutti i nomi di bucket esistenti in Amazon S3. Una delle possibilità per garantire l'univocità consiste nell'aggiungere il nome dell'organizzazione come prefisso ai nomi dei bucket. I nomi di bucket devono soddisfare determinati requisiti. Per ulteriori informazioni, consultare [ Restrizioni e limitazioni dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) nella *Guida per l'utente di Amazon Simple Storage Service.*
1. Scegli le impostazioni predefinite suggerite per le restanti opzioni.
1. Seleziona **Crea bucket**.
Una volta che Amazon S3 ha completato la creazione del bucket, la console visualizza il bucket vuoto nel pannello **Bucket**.
1. Creare una cartella.
1. Scelta del nome del bucket.
1. Scegli il pulsante **Crea cartella**.
1. Assegnare il nome **load** alla nuova cartella.
**Nota**
Il bucket creato non è in una sandbox. In questo esercizio aggiungi oggetti a un vero bucket. Per il tempo in cui conservi gli oggetti nel bucket, ti viene addebitato un importo nominale. Per maggiori informazioni sui prezzi di Amazon S3, consultare [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
1. Caricare i file di dati nel nuovo bucket Amazon S3.
1. Scegliere il nome della cartella di dati.
1. Nella procedura guidata Carica scegli **Aggiungi file**.
Segui le istruzioni della console Amazon S3 per caricare tutti i file scaricati ed estratti,
1. Scegli **Carica**.
**Credenziali utente**
Il comando COPY di Amazon Redshift deve avere accesso in lettura agli oggetti file nel bucket Amazon S3. Se si utilizzano le stesse credenziali utente per creare il bucket Amazon S3 ed eseguire il comando COPY di Amazon Redshift, questo comando disporrà di tutte le autorizzazioni necessarie. Se si desidera utilizzare credenziali utente differenti, è possibile concedere l'accesso utilizzando i controlli accessi di Amazon S3. Il comando Amazon Redshift COPY richiede almeno due ListBucket GetObject autorizzazioni per accedere agli oggetti file nel bucket Amazon S3. Per ulteriori informazioni sul controllo degli accessi ad Amazon S3, consultare [Gestione delle autorizzazioni di accesso alle risorse Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html).
## Fase 4: creazione delle tabelle di esempio
Per questo tutorial utilizza un set di tabelle basate sullo schema Star Schema Benchmark (SSB). Il diagramma seguente mostra il modello di dati SSB.
![\[Le cinque tabelle dello schema SSB e le relazioni reciproche.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/tutorial-optimize-tables-ssb-data-model.png)
Le tabelle SSB potrebbero già essere presenti nel database corrente. In tal caso eliminale dal database prima di crearle con i comandi CREATE TABLE nella fase successiva. Le tabelle utilizzate in questo tutorial potrebbero avere attributi differenti rispetto alla tabelle esistenti.
**Per creare le tabelle di esempio**
1. Per eliminare le tabelle SSB, eseguire i seguenti comandi nel client SQL.
```
drop table part cascade;
drop table supplier;
drop table customer;
drop table dwdate;
drop table lineorder;
```
1. Eseguire i seguenti comandi CREATE TABLE nel client SQL.
```
CREATE TABLE part
(
p_partkey INTEGER NOT NULL,
p_name VARCHAR(22) NOT NULL,
p_mfgr VARCHAR(6),
p_category VARCHAR(7) NOT NULL,
p_brand1 VARCHAR(9) NOT NULL,
p_color VARCHAR(11) NOT NULL,
p_type VARCHAR(25) NOT NULL,
p_size INTEGER NOT NULL,
p_container VARCHAR(10) NOT NULL
);
CREATE TABLE supplier
(
s_suppkey INTEGER NOT NULL,
s_name VARCHAR(25) NOT NULL,
s_address VARCHAR(25) NOT NULL,
s_city VARCHAR(10) NOT NULL,
s_nation VARCHAR(15) NOT NULL,
s_region VARCHAR(12) NOT NULL,
s_phone VARCHAR(15) NOT NULL
);
CREATE TABLE customer
(
c_custkey INTEGER NOT NULL,
c_name VARCHAR(25) NOT NULL,
c_address VARCHAR(25) NOT NULL,
c_city VARCHAR(10) NOT NULL,
c_nation VARCHAR(15) NOT NULL,
c_region VARCHAR(12) NOT NULL,
c_phone VARCHAR(15) NOT NULL,
c_mktsegment VARCHAR(10) NOT NULL
);
CREATE TABLE dwdate
(
d_datekey INTEGER NOT NULL,
d_date VARCHAR(19) NOT NULL,
d_dayofweek VARCHAR(10) NOT NULL,
d_month VARCHAR(10) NOT NULL,
d_year INTEGER NOT NULL,
d_yearmonthnum INTEGER NOT NULL,
d_yearmonth VARCHAR(8) NOT NULL,
d_daynuminweek INTEGER NOT NULL,
d_daynuminmonth INTEGER NOT NULL,
d_daynuminyear INTEGER NOT NULL,
d_monthnuminyear INTEGER NOT NULL,
d_weeknuminyear INTEGER NOT NULL,
d_sellingseason VARCHAR(13) NOT NULL,
d_lastdayinweekfl VARCHAR(1) NOT NULL,
d_lastdayinmonthfl VARCHAR(1) NOT NULL,
d_holidayfl VARCHAR(1) NOT NULL,
d_weekdayfl VARCHAR(1) NOT NULL
);
CREATE TABLE lineorder
(
lo_orderkey INTEGER NOT NULL,
lo_linenumber INTEGER NOT NULL,
lo_custkey INTEGER NOT NULL,
lo_partkey INTEGER NOT NULL,
lo_suppkey INTEGER NOT NULL,
lo_orderdate INTEGER NOT NULL,
lo_orderpriority VARCHAR(15) NOT NULL,
lo_shippriority VARCHAR(1) NOT NULL,
lo_quantity INTEGER NOT NULL,
lo_extendedprice INTEGER NOT NULL,
lo_ordertotalprice INTEGER NOT NULL,
lo_discount INTEGER NOT NULL,
lo_revenue INTEGER NOT NULL,
lo_supplycost INTEGER NOT NULL,
lo_tax INTEGER NOT NULL,
lo_commitdate INTEGER NOT NULL,
lo_shipmode VARCHAR(10) NOT NULL
);
```
## Fase 5: esecuzione dei comandi COPY
In questa fase, esegui i comandi COPY per caricare ognuna della tabelle nello schema SSB. Gli esempi relativi al comando COPY illustrano il caricamento da differenti formati di file mediante varie opzioni del comando COPY nonché la risoluzione degli errori di caricamento.
### Sintassi del comando COPY
La sintassi di base del comando [COPY](r_COPY.md) è descritta di seguito.
```
COPY table_name [ column_list ] FROM data_source CREDENTIALS access_credentials [options]
```
Per eseguire un comando COPY, fornisci i valori seguenti.
**Nome tabella**
La tabella di destinazione per il comando COPY. La tabella deve esistere già nel database. La tabella può essere temporanea o persistente. Il comando COPY aggiunge i nuovi dati di input a tutte le righe esistenti nella tabella.
**Elenco di colonne**
Per impostazione predefinita, COPY carica i campi dai dati di origine nelle colonne della tabella nell'ordine. Puoi eventualmente specificare un *elenco di colonne*, ovvero un elenco di nomi di colonna separati da virgole, per associare i campi dei dati a colonne specifiche. In questo tutorial, non utilizzi elenchi di colonne. Per ulteriori informazioni, consultare [Column List](copy-parameters-column-mapping.md#copy-column-list) nel riferimento del comando COPY.
Origine dati
È possibile utilizzare il comando COPY per caricare dati da un bucket Amazon S3, un cluster Amazon EMR, un host remoto mediante una connessione SSH oppure da una tabella Amazon DynamoDB. Per questo tutorial, i file di dati saranno caricati in un bucket Amazon S3. Durante il caricamento da Amazon S3 è necessario fornire il nome del bucket e la posizione dei file di dati. Per farlo, indicare un percorso dell'oggetto per i file di dati o la posizione di un file manifest che elenchi esplicitamente ogni file di dati e la sua posizione.
+ Prefisso della chiave
Un oggetto archiviato in Amazon S3 è identificato in modo univoco da una chiave oggetto che include il nome del bucket, gli eventuali nomi delle cartelle e il nome dell'oggetto. Un *prefisso della chiave *fa riferimento a un insieme di oggetti con lo stesso prefisso. Il percorso oggetto è un prefisso di chiave che il comando COPY utilizza per caricare tutti gli oggetti che condividono quel prefisso. Ad esempio, il prefisso di chiave `custdata.txt` può fare riferimento a un singolo file o a un insieme di file, ad esempio `custdata.txt.001`, `custdata.txt.002` e così di seguito.
+ File manifest
In alcuni casi, potrebbe essere necessario caricare file con prefissi diversi, ad esempio da più bucket o cartelle. In altri, potrebbe essere necessario escludere i file che condividono un prefisso. In questi casi, è possibile utilizzare un file manifest. Un *file manifest* elenca esplicitamente ogni file di caricamento e la relativa chiave oggetto univoca. Utilizzi un file manifest per caricare la tabella PART più avanti in questo tutorial.
**Credenziali**
Per accedere alle AWS risorse che contengono i dati da caricare, devi fornire le credenziali di AWS accesso a un utente con privilegi sufficienti. Queste credenziali includono un ruolo IAM (ARN) Amazon Resource Name (ARN). Per caricare dati da Amazon S3, le credenziali devono includere ListBucket e autorizzazioni. GetObject Ulteriori credenziali sono necessarie se i dati sono crittografati. Per ulteriori informazioni, consultare [Parametri di autorizzazione](copy-parameters-authorization.md) nel riferimento del comando COPY. Per ulteriori informazioni sulla gestione degli accessi, consultare [Gestione delle autorizzazioni di accesso alle risorse Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html).
Opzioni
Puoi specificare vari parametri con il comando COPY per definire formati di file, gestire formati di dati, gestire errori e controllare altre funzionalità. In questo tutorial, utilizzi le seguenti opzioni e funzionalità del comando COPY:
+ Prefisso della chiave
Per informazioni su come caricare da più file specificando un prefisso chiave, consultare [Caricamento della tabella PART mediante NULL AS](#tutorial-loading-load-part).
+ Formato CSV
Per informazioni su come caricare i dati in formato CSV, consultare [Caricamento della tabella PART mediante NULL AS](#tutorial-loading-load-part).
+ NULL AS
Per informazioni su come caricare PART utilizzando l'opzione NULL AS, consultare [Caricamento della tabella PART mediante NULL AS](#tutorial-loading-load-part).
+ Formato delimitato da carattere
Per informazioni su come utilizzare l'opzione DELIMITER, consultare [Opzioni DELIMITER e REGION](#tutorial-loading-load-supplier).
+ REGION
Per informazioni su come utilizzare l'opzione REGION, consultare [Opzioni DELIMITER e REGION](#tutorial-loading-load-supplier).
+ Larghezza di formato fisso
Per informazioni su come caricare la tabella CUSTOMER dai dati a larghezza fissa, consultare [Caricamento della tabella CUSTOMER mediante MANIFEST](#tutorial-loading-load-customer).
+ MAXERROR
Per informazioni su come utilizzare l'opzione MAXERROR, consultare [Caricamento della tabella CUSTOMER mediante MANIFEST](#tutorial-loading-load-customer).
+ ACCEPTINVCHARS
Per informazioni su come utilizzare l'opzione ACCEPTINVCHARS, consultare [Caricamento della tabella CUSTOMER mediante MANIFEST](#tutorial-loading-load-customer).
+ MANIFEST
Per informazioni su come utilizzare l'opzione MANIFEST, consultare [Caricamento della tabella CUSTOMER mediante MANIFEST](#tutorial-loading-load-customer).
+ DATEFORMAT
Per informazioni su come utilizzare l'opzione DATEFORMAT, consultare [Caricamento della tabella DWDATE mediante DATEFORMAT](#tutorial-loading-load-dwdate).
+ GZIP, LZOP e BZIP2
Per informazioni su come comprimere i file, consultare [Caricare più file di dati](#tutorial-loading-load-lineorder).
+ COMPUPDATE
Per informazioni su come utilizzare l'opzione COMPUPDATE, consultare [Caricare più file di dati](#tutorial-loading-load-lineorder).
+ Molteplici file
Per informazioni su come caricare più file, consultare [Caricare più file di dati](#tutorial-loading-load-lineorder).
### Caricamento delle tabelle SSB
Per caricare ognuna delle tabelle nello schema SSB, utilizzi i comandi COPY seguenti. Ogni comando comporta opzioni COPY e tecniche di risoluzione dei problemi differenti.
Per caricare le tabelle SSB:
1. [Sostituisci il nome e le credenziali del bucket AWS](#tutorial-loading-run-copy-replaceables)
1. [Caricamento della tabella PART mediante NULL AS](#tutorial-loading-load-part)
1. [Caricamento della tabella CUSTOMER mediante MANIFEST](#tutorial-loading-load-customer)
1. [Caricamento della tabella DWDATE mediante DATEFORMAT](#tutorial-loading-load-dwdate)
#### Sostituisci il nome e le credenziali del bucket AWS
I comandi COPY in questo tutorial hanno il formato illustrato di seguito.
```
copy table from 's3:///load/key_prefix'
credentials 'aws_iam_role=arn:aws:iam:::role/'
options;
```
Per ogni comando COPY:
1. Sostituiscilo ** con il nome di un bucket nella stessa regione del cluster.
Questa fase presuppone che il bucket e il cluster siano nella stessa regione. In alternativa, è possibile specificare regione utilizzando l'opzione [REGION](copy-parameters-data-source-s3.md#copy-region) con il comando COPY.
1. Sostituisci ** e ** con il tuo ruolo Account AWS e quello di IAM. Il segmento della stringa delle credenziali racchiuso tra virgolette singole non deve contenere spazi o interruzioni di riga. Tieni presente che l'ARN potrebbe differire leggermente nel formato rispetto all'esempio. È consigliabile copiare l'ARN per il ruolo dalla console IAM, per assicurarsi che sia accurato, quando esegui i comandi COPY.
#### Caricamento della tabella PART mediante NULL AS
In questa fase, utilizzi le opzioni CSV e NULL AS per caricare la tabella PART.
Il comando COPY consente il caricamento di dati da più file in parallelo, che è un'operazione molto più rapida rispetto al caricamento da un singolo file. Per illustrare questo principio, i dati di ogni tabella in questo tutorial sono suddivisi in otto file, anche se i file sono molto piccoli. In una fase successiva, confronterai la differenza di tempo tra il caricamento da un singolo file e da più file. Per ulteriori informazioni, consulta [Caricamento di file di dati](c_best-practices-use-multiple-files.md).
**Prefisso della chiave**
Puoi eseguire i caricamenti da più file specificando un prefisso di chiave per il set di file oppure elencando esplicitamente i file in un file manifest. In questa fase, utilizzerai un prefisso della chiave. In una fase successiva, utilizzerai un file manifest. Il prefisso di chiave `'s3://amzn-s3-demo-bucket/load/part-csv.tbl'` carica il seguente set di file nella cartella `load`.
```
part-csv.tbl-000
part-csv.tbl-001
part-csv.tbl-002
part-csv.tbl-003
part-csv.tbl-004
part-csv.tbl-005
part-csv.tbl-006
part-csv.tbl-007
```
**Formato CSV**
CSV, acronimo di Comma Separated Values (valori separati da virgole), è un formato comune per l'importazione e l'esportazione di dati di fogli di calcolo. CSV è più flessibile del formato delimitato da virgole in quanto ti consente di includere stringhe tra virgolette nei campi. Le virgolette di delimitazione predefinite per COPY dal formato CSV sono le virgolette doppie ("), ma è possibile specificare un altro tipo di virgolette utilizzando l'opzione QUOTE AS. Quando si utilizzano le virgolette di delimitazione nel campo, creare una sequenza di escape aggiungendo virgolette di delimitazione aggiuntive.
Il seguente estratto da un file di dati in formato CSV della tabella PART mostra delle stringhe racchiuse tra virgolette doppie (`"LARGE ANODIZED BRASS"`). Mostra anche una stringa racchiusa tra doppie virgolette all'interno di una stringa di citazion (`"MEDIUM ""BURNISHED"" TIN"`).
```
15,dark sky,MFGR#3,MFGR#47,MFGR#3438,indigo,"LARGE ANODIZED BRASS",45,LG CASE
22,floral beige,MFGR#4,MFGR#44,MFGR#4421,medium,"PROMO, POLISHED BRASS",19,LG DRUM
23,bisque slate,MFGR#4,MFGR#41,MFGR#4137,firebrick,"MEDIUM ""BURNISHED"" TIN",42,JUMBO JAR
```
I dati della tabella PART contengono caratteri che generano un errore nell'esecuzione del comando COPY. In questo esercizio, individuiamo e correggiamo tali errori.
Per caricare i dati in formato CSV, aggiungi `csv` al comando COPY. Esegui il comando seguente per caricare la tabella PART.
```
copy part from 's3:///load/part-csv.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
csv;
```
Potrebbe essere visualizzato un messaggio di errore simile al seguente.
```
An error occurred when executing the SQL command:
copy part from 's3://amzn-s3-demo-bucket/load/part-csv.tbl'
credentials' ...
ERROR: Load into table 'part' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000]
Execution time: 1.46s
1 statement(s) failed.
1 statement(s) failed.
```
Per ottenere maggiori informazioni sull'errore, esegui una query sulla tabella STL\$1LOAD\$1ERRORS. La query seguente utilizza la funzione SUBSTRING per ridurre le colonne e facilitare la lettura e utilizza LIMIT 10 per ridurre il numero di righe restituite. Puoi regolare i valori in `substring(filename,22,25)` allo scopo di includere la lunghezza del nome di bucket.
```
select query, substring(filename,22,25) as filename,line_number as line,
substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text,
substring(raw_field_value,0,15) as field_text,
substring(err_reason,0,45) as reason
from stl_load_errors
order by query desc
limit 10;
```
```
query | filename | line | column | type | pos |
--------+-------------------------+-----------+------------+------------+-----+----
333765 | part-csv.tbl-000 | 1 | | | 0 |
line_text | field_text | reason
------------------+------------+----------------------------------------------
15,NUL next, | | Missing newline: Unexpected character 0x2c f
```
**NULL AS**
I fila di dati `part-csv.tbl` utilizzano il carattere di terminazione NUL (`\x000` o `\x0`) per indicare valori NULL.
**Nota**
Nonostante un'ortografia molto simile, NUL e NULL non sono identici. NUL è un carattere UTF-8 con punto di codice `x000`, spesso utilizzato per indicare la fine del record. NULL è un valore SQL che rappresenta l'assenza di dati.
Per impostazione predefinita, COPY tratta un carattere di terminazione NUL come carattere di fine record e termina il record, generando spesso risultati imprevisti o un errore. Non esiste un singolo metodo standard per indicare NULL in un dato testuale. Perciò l'opzione NULL AS del comando COPY ti consente di specificare quale carattere sostituire con NULL durante il caricamento della tabella. In questo esempio, vuoi che COPY consideri il carattere di terminazione NUL come valore NULL.
**Nota**
La colonna della tabella che riceve il valore NULL deve essere configurata come *nullable* Ciò significa che non deve includere il vincolo NOT NULL nella specifica CREATE TABLE.
Per caricare la tabella PART utilizzando l'opzione NULL AS, esegui il comando COPY seguente.
```
copy part from 's3:///load/part-csv.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
csv
null as '\000';
```
Per verificare che COPY ha caricato i valori NULL, esegui il comando seguente per selezionare solo le righe che contengono NULL.
```
select p_partkey, p_name, p_mfgr, p_category from part where p_mfgr is null;
```
```
p_partkey | p_name | p_mfgr | p_category
-----------+----------+--------+------------
15 | NUL next | | MFGR#47
81 | NUL next | | MFGR#23
133 | NUL next | | MFGR#44
(2 rows)
```
#### Opzioni DELIMITER e REGION
Le opzioni DELIMITER e REGION sono importanti per capire come caricare i dati.
**Formato delimitato da carattere**
I campi in un file delimitato da carattere sono separati da uno specifico carattere, ad esempio una barra verticale ( \$1 ), una virgola ( , ) o una tabulazione ( \$1t ). I file delimitati da carattere possono utilizzare qualsiasi carattere ASCII, inclusi i caratteri ASCII non stampabili, come delimitatore. Per specificare il carattere delimitatore, utilizzi l'opzione DELIMITER. Il delimitatore predefinito è una barra verticale ( \$1 ).
L'estratto seguente dei dati della tabella SUPPLIER utilizza il formato delimitato da una barra verticale.
```
1|1|257368|465569|41365|19950218|2-HIGH|0|17|2608718|9783671|4|2504369|92072|2|19950331|TRUCK
1|2|257368|201928|8146|19950218|2-HIGH|0|36|6587676|9783671|9|5994785|109794|6|19950416|MAIL
```
**REGION**
Quando possibile, dovresti collocare i dati di carico nella stessa AWS regione del cluster Amazon Redshift. Se tali dati e il cluster si trovano nella stessa regione, si riduce la latenza e si evitano i costi di trasferimento dei dati tra regioni. Per ulteriori informazioni, consulta [Best practice di Amazon Redshift per il caricamento di dati](c_loading-data-best-practices.md).
Se devi caricare dati da una AWS regione diversa, utilizza l'opzione REGION per specificare la AWS regione in cui si trovano i dati di caricamento. Se specifichi una regione, tutti i dati di caricamento, inclusi i file manifest, devono trovarsi in tale regione. Per ulteriori informazioni, consulta [REGION](copy-parameters-data-source-s3.md#copy-region).
Ad esempio, se il cluster si trova nella Regione Stati Uniti orientali (Virginia settentrionale) e il bucket Amazon S3 si trova nella Regione Stati Uniti occidentali (Oregon), il comando COPY seguente mostra come caricare la tabella SUPPLIER a partire dai dati delimitati da barra verticale.
```
copy supplier from 's3://amzn-s3-demo-bucket/ssb/supplier.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
delimiter '|'
gzip
region 'us-west-2';
```
#### Caricamento della tabella CUSTOMER mediante MANIFEST
In questa fase, utilizzi le opzioni FIXEDWIDTH, MAXERROR, ACCEPTINVCHARS e MANIFEST per caricare la tabella CUSTOMER.
I dati di esempio per questo esercizio contengono caratteri che genereranno errori quando il comando COPY tenta di caricarli. Utilizzi l'opzione MAXERRORS e la tabella di sistema STL\$1LOAD\$1ERRORS per risolvere gli errori di caricamento e quindi le opzioni ACCEPTINVCHARS e MANIFEST per eliminare gli errori.
**Formato a larghezza fissa**
Il formato a larghezza fissa definisce ogni campo come numero di caratteri fisso e non separa i campi con un delimitatore. L'estratto seguente dei dati della tabella CUSTOMER utilizza il formato a larghezza fissa.
```
1 Customer#000000001 IVhzIApeRb MOROCCO 0MOROCCO AFRICA 25-705
2 Customer#000000002 XSTf4,NCwDVaWNe6tE JORDAN 6JORDAN MIDDLE EAST 23-453
3 Customer#000000003 MG9kdTD ARGENTINA5ARGENTINAAMERICA 11-783
```
L'ordine delle label/width coppie deve corrispondere esattamente all'ordine delle colonne della tabella. Per ulteriori informazioni, consulta [FIXEDWIDTH](copy-parameters-data-format.md#copy-fixedwidth).
La stringa di specifica a larghezza fissa per i dati della tabella CUSTOMER è la seguente.
```
fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15,
c_region :12, c_phone:15,c_mktsegment:10'
```
Per caricare la tabella CUSTOMER a partire dai dati a larghezza, esegui il comando seguente.
```
copy customer
from 's3:///load/customer-fw.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10';
```
Dovrebbe essere visualizzato un messaggio di errore simile al seguente.
```
An error occurred when executing the SQL command:
copy customer
from 's3://amzn-s3-demo-bucket/load/customer-fw.tbl'
credentials'...
ERROR: Load into table 'customer' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000]
Execution time: 2.95s
1 statement(s) failed.
```
**MAXERROR**
Per impostazione predefinita, al primo errore, il comando COPY non riesce e restituisce un messaggio di errore. Per risparmiare tempo durante il testing, puoi utilizzare l'opzione MAXERROR per indicare a COPY di ignorare un determinato numero di errori prima di avere esito negativo. Poiché ci aspettiamo degli errori la prima volta che testiamo il caricamento dei dati della tabella CUSTOMER, aggiungi `maxerror 10` al comando COPY.
Per eseguire il test utilizzando le opzioni FIXEDWIDTH e MAXERROR, esegui il comando seguente.
```
copy customer
from 's3:///load/customer-fw.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10'
maxerror 10;
```
Questa volta, anziché un messaggio di errore, viene restituito un messaggio simile al seguente.
```
Warnings:
Load into table 'customer' completed, 112497 record(s) loaded successfully.
Load into table 'customer' completed, 7 record(s) could not be loaded. Check 'stl_load_errors' system table for details.
```
L'avviso segnala che sono stati rilevati sette errori durante l'esecuzione di COPY. Per verificare gli errori, esegui una query sulla tabella STL\$1LOAD\$1ERRORS, come mostrato nell'esempio seguente.
```
select query, substring(filename,22,25) as filename,line_number as line,
substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text,
substring(raw_field_value,0,15) as field_text,
substring(err_reason,0,45) as error_reason
from stl_load_errors
order by query desc, filename
limit 7;
```
I risultati della query STL\$1LOAD\$1ERRORS devono essere simili a quanto segue.
```
query | filename | line | column | type | pos | line_text | field_text | error_reason
--------+---------------------------+------+-----------+------------+-----+-------------------------------+------------+----------------------------------------------
334489 | customer-fw.tbl.log | 2 | c_custkey | int4 | -1 | customer-fw.tbl | customer-f | Invalid digit, Value 'c', Pos 0, Type: Integ
334489 | customer-fw.tbl.log | 6 | c_custkey | int4 | -1 | Complete | Complete | Invalid digit, Value 'C', Pos 0, Type: Integ
334489 | customer-fw.tbl.log | 3 | c_custkey | int4 | -1 | #Total rows | #Total row | Invalid digit, Value '#', Pos 0, Type: Integ
334489 | customer-fw.tbl.log | 5 | c_custkey | int4 | -1 | #Status | #Status | Invalid digit, Value '#', Pos 0, Type: Integ
334489 | customer-fw.tbl.log | 1 | c_custkey | int4 | -1 | #Load file | #Load file | Invalid digit, Value '#', Pos 0, Type: Integ
334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8
334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8
(7 rows)
```
Esaminando i risultati, è possibile notare che vi sono due messaggi nella colonna `error_reasons`:
+
```
Invalid digit, Value '#', Pos 0, Type: Integ
```
Questi errori sono dovuti al file `customer-fw.tbl.log`. Il problema è che si tratta di un file di log e non di un file di dati, quindi non dovrebbe essere caricato. Puoi utilizzare un file manifest per evitare di caricare file non appropriati.
+
```
String contains invalid or unsupported UTF8
```
Il tipo di dati VARCHAR supporta caratteri UTF-8 di al massimo tre byte. Se i dati di caricamento contengono caratteri non supportati o non validi, puoi utilizzare l'opzione ACCEPTINVCHARS per sostituire ogni carattere non valido con un carattere alternativo specificato.
Un altro problema con il carico è più difficile da rilevare: il carico ha prodotto risultati imprevisti. Per analizzare questo problema, esegui una query sulla tabella CUSTOMER con il comando seguente.
```
select c_custkey, c_name, c_address
from customer
order by c_custkey
limit 10;
```
```
c_custkey | c_name | c_address
-----------+---------------------------+---------------------------
2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE
2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE
3 | Customer#000000003 | MG9kdTD
3 | Customer#000000003 | MG9kdTD
4 | Customer#000000004 | XxVSJsL
4 | Customer#000000004 | XxVSJsL
5 | Customer#000000005 | KvpyuHCplrB84WgAi
5 | Customer#000000005 | KvpyuHCplrB84WgAi
6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx
6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx
(10 rows)
```
Le righe devono essere univoche, ma in questo caso si hanno dei duplicati.
Un altro modo di rilevare risultati imprevisti è di verificare il numero di righe caricate. Nel nostro caso, avremmo dovuto avere 100000 righe caricate, ma il messaggio ha segnalato 112497 record. Le righe in eccesso sono state caricate in quanto il comando COPY ha caricato un file estraneo, `customer-fw.tbl0000.bak`.
In questo esercizio, utilizzi un file manifest per evitare di caricare i file non appropriati.
**ACCEPTINVCHARS**
Per impostazione predefinita, quando COPY incontra un carattere non supportato dal tipo di dati della colonna, ignora la riga e restituisce un errore. Per informazioni sui caratteri UTF-8 non validi, consultare [Errori di caricamento di caratteri multibyte](multi-byte-character-load-errors.md).
Potresti utilizzare l'opzione MAXERRORS per ignorare gli errori e continuare il caricamento, quindi eseguire una query su STL\$1LOAD\$1ERRORS per individuare i caratteri non validi e infine correggere i file di dati. Tuttavia, MAXERRORS è più appropriato per risolvere i problemi di caricamento e in genere non dovrebbe essere utilizzato in un ambiente di produzione.
L'opzione ACCEPTINVCHARS è generalmente una scelta più adatta per la gestione di caratteri non validi. ACCEPTINVCHARS indica a COPY di sostituire ogni carattere non valido con un carattere valido specificato e di proseguire l'operazione di caricamento. Come carattere sostitutivo puoi specificare qualsiasi carattere ASCII valido tranne NULL. Il carattere sostitutivo predefinito è un punto interrogativo (?). COPY sostituisce i caratteri multibyte con una stringa sostitutiva della stessa lunghezza. Ad esempio, un carattere di 4 byte viene sostituito da `'????'`.
COPIA restituisce il numero di righe che contenevano caratteri UTF-8 non validi. Aggiunge inoltre una voce alla tabella di sistema STL\$1REPLACEMENTS per ogni riga interessata, fino a un massimo di 100 righe per sezione di nodo. Vengono sostituiti anche altri caratteri UTF-8 non validi, ma gli eventi di sostituzione non vengono registrati.
ACCEPTINVCHARS è valido solo per le colonne VARCHAR.
Per questa fase, aggiungi ACCEPTINVCHARS con il carattere sostitutivo `'^'`.
**MANIFEST**
Quando si esegue una copia da Amazon S3 con COPY utilizzando un prefisso della chiave, esiste il rischio di caricare tabelle non desiderate. Ad esempio, la cartella `'s3://amzn-s3-demo-bucket/load/` contiene otto file di dati che condividono il prefisso di chiave `customer-fw.tbl`: `customer-fw.tbl0000`, `customer-fw.tbl0001` e così di seguito. Tuttavia, la stessa cartella contiene anche file estranei, ovvero `customer-fw.tbl.log` e `customer-fw.tbl-0001.bak`.
Per essere certo di caricare tutti i file corretti e solo quelli, utilizza un file manifest. Il manifest è un file di testo in formato JSON che elenca esplicitamente la chiave oggetto univoca di ogni file di origine da caricare. Gli oggetti file possono essere in cartelle o in bucket differenti, ma nella stessa regione. Per ulteriori informazioni, consulta [MANIFEST](copy-parameters-data-source-s3.md#copy-manifest).
Quanto segue mostra il testo `customer-fw-manifest`.
```
{
"entries": [
{"url":"s3:///load/customer-fw.tbl-000"},
{"url":"s3:///load/customer-fw.tbl-001"},
{"url":"s3:///load/customer-fw.tbl-002"},
{"url":"s3:///load/customer-fw.tbl-003"},
{"url":"s3:///load/customer-fw.tbl-004"},
{"url":"s3:///load/customer-fw.tbl-005"},
{"url":"s3:///load/customer-fw.tbl-006"},
{"url":"s3:///load/customer-fw.tbl-007"}
]
}
```
**Per caricare i dati per la tabella CUSTOMER mediante un file manifest**
1. Aprire il file `customer-fw-manifest` in un editor di testo.
1. Sostituisci ** con il nome del tuo bucket.
1. Salvare il file.
1. Caricare il file nella cartella di caricamento del bucket.
1. Esegui il seguente comando COPY.
```
copy customer from 's3:///load/customer-fw-manifest'
credentials 'aws_iam_role=arn:aws:iam:::role/'
fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10'
maxerror 10
acceptinvchars as '^'
manifest;
```
#### Caricamento della tabella DWDATE mediante DATEFORMAT
In questa fase, utilizzi le opzioni DELIMITER and DATEFORMAT per caricare la tabella DWDATE.
Quando si caricano le colonne DATE e TIMESTAMP, COPY prevede il formato predefinito, che è YYYY-MM-DD per le date e YYYY-MM-DD HH:MI:SS per i timestamp. Se i dati di caricamento non utilizzano il formato predefinito, puoi utilizzare DATEFORMAT e TIMEFORMAT per specificare il formato.
L'estratto seguente mostra i formati di data nella tabella DWDATE. Nota la discordanza tra i formati di data nella seconda colonna.
```
19920104 1992-01-04 Sunday January 1992 199201 Jan1992 1 4 4 1...
19920112 January 12, 1992 Monday January 1992 199201 Jan1992 2 12 12 1...
19920120 January 20, 1992 Tuesday January 1992 199201 Jan1992 3 20 20 1...
```
**DATEFORMAT**
Puoi specificare un solo formato di data. Se i dati di caricamento contengono formati discordanti in varie colonne o se il formato non è noto al momento del caricamento, utilizza DATEFORMAT con l'argomento `'auto'`. Quando `'auto'` è specificato, COPY riconoscerà qualsiasi formato di data o ora valido e lo convertirà nel formato predefinito. L'opzione `'auto'` riconosce diversi formati che non sono supportati quando si utilizza una stringa DATEFORMAT e TIMEFORMAT. Per ulteriori informazioni, consulta [Utilizzo del riconoscimento automatico con DATEFORMAT e TIMEFORMAT](automatic-recognition.md).
Per caricare la tabella DWDATE, esegui il comando COPY seguente.
```
copy dwdate from 's3:///load/dwdate-tab.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
delimiter '\t'
dateformat 'auto';
```
#### Caricare più file di dati
Puoi utilizzare le opzioni GZIP e COMPUPDATE per caricare una tabella.
Puoi caricare una tabella da un singolo file di dati o da più file. In questo modo puoi confrontare i tempi di caricamento dei due metodi.
**GZIP, LZOP e BZIP2**
Puoi comprimere i tuoi file utilizzando i formati di compressione gzip, lzop o bzip2. Nel caso di caricamento da file compressi, COPY decomprime i file durante il processo di caricamento. La compressione di file consente di risparmiare spazio di storage e riduce i tempi di caricamento.
**COMPUPDATE**
Quando COPY carica una tabella vuota senza codifiche di compressione, analizza i dati di caricamento per determinare le codifiche ottimali. Modifica quindi la tabella per utilizzare tali codifiche prima dell'inizio del caricamento. Questo processo di analisi richiede tempo, ma è necessario al massimo una sola volta per tabella. Per risparmiare tempo, puoi ignorare questa fese disattivando COMPUPDATE. Per consentire una valutazione accurata dei tempi di copia con il comando COPY, disattivi COMPUPDATE per questa fase.
**Molteplici file**
Il comando COPY consente caricamenti di dati estremamente efficaci quando vengono eseguiti da molteplici file in parallelo anziché da un singolo file. Dividi i dati in file in modo che il numero di file sia un multiplo del numero di sezioni nel cluster. Facendolo, Amazon Redshift divide il carico di lavoro e distribuisce i dati in modo omogeneo tra le sezioni del cluster. Il numero di sezioni per nodo dipende dalla dimensione dei nodi del cluster. Per ulteriori informazioni sul numero di sezioni per ogni dimensione di nodo, consulta [Informazioni su cluster e nodi](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) nella *Guida alla gestione di Amazon Redshift*.
Ad esempio, i nodi di calcolo del cluster in questo tutorial hanno due sezioni ciascuno. In altre parole un cluster a quattro nodi ha otto sezioni. Nelle fasi precedenti, i dati di caricamento erano contenuti in otto file, anche se i file erano molto piccoli. Puoi confrontare la differenza di tempo tra il caricamento da un singolo file voluminoso e quello da più file.
Anche i file che contengono 15 milioni di record e occupano circa 1,2 GB sono molto piccoli nel contesto di Amazon Redshift. Ma sono sufficienti per dimostrare i vantaggi prestazionali inerenti al caricamento da più file.
L’immagine seguente mostra i file di dati per LINEORDER.
![\[I dati nella tabella LINEORDER sono suddivisi in nove file.\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/images/tutorial-load-lineorder-files.png)
**Per valutare le prestazioni di COPY con molteplici file**
1. In un test di laboratorio, il comando seguente è stato eseguito per COPIARE da un singolo file. Questo comando mostra un bucket fittizio.
```
copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-single.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
gzip
compupdate off
region 'us-east-1';
```
1. I risultati sono stati i seguenti. Notare il tempo di esecuzione.
```
Warnings:
Load into table 'lineorder' completed, 14996734 record(s) loaded successfully.
0 row(s) affected.
copy executed successfully
Execution time: 51.56s
```
1. Quindi è stato eseguito il comando seguente per effettuare COPIARE da più file.
```
copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-multi.tbl'
credentials 'aws_iam_role=arn:aws:iam:::role/'
gzip
compupdate off
region 'us-east-1';
```
1. I risultati sono stati i seguenti. Notare il tempo di esecuzione.
```
Warnings:
Load into table 'lineorder' completed, 14996734 record(s) loaded successfully.
0 row(s) affected.
copy executed successfully
Execution time: 17.7s
```
1. Confrontare i tempi di esecuzione.
Nel nostro esperimento, il tempo per caricare 15 milioni di record è passato da 51,56 secondi a 17,7 secondi, una riduzione del 65,7%.
Questi risultati sono basati sull'utilizzo di un cluster a quattro nodi. Se il cluster utilizzato ha più nodi, il risparmio di tempo sarà ancora maggiore. Per i cluster Amazon Redshift tipici, con decine di migliaia di nodi, la differenza sarà ancora più spettacolare. Se invece si dispone di un cluster a nodo singolo, la differenza tra i tempi di esecuzione sarà minima.
## Fase 6: vacuum e analisi del database
Quando aggiungi, elimini o modifichi un numero significativo di righe, devi eseguire un comando VACUUM e quindi il comando ANALYZE. Un comando *VACUUM* recupera lo spazio dalle righe eliminate e ripristina l'ordinamento. Il comando ANALYZE aggiorna i metadati delle statistiche, consentendo all'ottimizzatore di query di generare piani di query più accurati. Per ulteriori informazioni, consulta [Vacuum delle tabelle](t_Reclaiming_storage_space202.md).
Se carichi i dati in base all'ordine delle chiavi di ordinamento, un vacuum è alquanto veloce. In questo tutorial, hai aggiunto un numero importante di righe, ma le hai aggiunte a delle tabelle vuote. Inoltre, non hai eliminato delle righe, di conseguenza non è necessario eseguire un riordinamento. COPY aggiorna automaticamente le statistiche dopo aver caricato una tabella vuota, quindi le tue statistiche dovrebbero esserlo. up-to-date Tuttavia, per una corretta manutenzione, completi questo tutorial eseguendo un'operazione di vacuum e analizzando il database.
Per eseguire un vacuum e analizzare il database, esegui i comandi seguenti.
```
vacuum;
analyze;
```
## Fase 7: elimina le risorse
Il tuo cluster genera dei costi fino a che è in esecuzione. Una volta completato questo tutorial, sarà quindi necessario ripristinare lo stato precedente dell'ambiente seguendo le istruzioni contenute nella [Fase 5: Revoca dell'accesso ed eliminazione del cluster di esempio](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) in *Guida alle operazioni di base di Amazon Redshift*.
Se vuoi conservare il cluster, ma recuperare lo storage utilizzato dalle tabelle SSB, esegui i comandi seguenti.
```
drop table part;
drop table supplier;
drop table customer;
drop table dwdate;
drop table lineorder;
```
### Next
[Riepilogo](#tutorial-loading-data-summary)
## Riepilogo
In questo tutorial, sono stati caricati file di dati in Amazon S3 e quindi sono stati utilizzati i comandi COPY per caricare dati di file nelle tabelle Amazon Redshift.
Hai caricato i dati utilizzando i seguenti formati:
+ Delimitato da carattere
+ CSV
+ A larghezza fissa
Hai utilizzato la tabella di sistema STL\$1LOAD\$1ERRORS e quindi le opzioni REGION, MANIFEST, MAXERROR, ACCEPTINVCHARS, DATEFORMAT e NULL AS per correggere gli errori di caricamento.
Hai applicato le seguenti best practice per il caricamento dei dati:
+ [Utilizzo di un comando COPY per il caricamento dei dati](c_best-practices-use-copy.md)
+ [Caricamento di file di dati](c_best-practices-use-multiple-files.md)
+ [Utilizzo di un singolo comando COPY per il caricamento da più file](c_best-practices-single-copy-command.md)
+ [Compressione dei file di dati](c_best-practices-compress-data-files.md)
+ [Verifica dei file di dati prima e dopo un caricamento](c_best-practices-verifying-data-files.md)
Per ulteriori informazioni sulle best practice di Amazon Redshift, fare riferimento ai seguenti collegamenti:
+ [Best practice di Amazon Redshift per il caricamento di dati](c_loading-data-best-practices.md)
+ [Best practice di Amazon Redshift per la progettazione di tabelle](c_designing-tables-best-practices.md)
+ [Best practice di Amazon Redshift per la progettazione di query](c_designing-queries-best-practices.md)