O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Carregar dados no Amazon Redshift Há algumas maneiras de carregar dados em um banco de dados do Amazon Redshift. Uma fonte conhecida de dados a serem carregados são os arquivos do Amazon S3. A tabela a seguir resume alguns métodos a serem usados diretamente de uma fonte do Amazon S3. | Método a ser usado | Descrição | Quando o método é necessário | | --- | --- | --- | | COPY command | Executa uma ingestão de arquivos em lote para carregar dados dos arquivos do Amazon S3. Esse método utiliza processamento paralelo do Amazon Redshift. Para obter mais informações, consulte [Carregar tabelas com o comando COPY](t_Loading_tables_with_the_COPY_command.md). | Deve ser usado quando são necessários requisitos básicos de carregamento de dados para iniciar a ingestão manual de arquivos em lote. Esse método é usado principalmente com pipelines de ingestão de arquivos personalizados e de terceiros ou workloads de ingestão de arquivos únicas ou ad hoc. | | COPY... Comando CREATE JOB (cópia automática) | Executa seus comandos COPY automaticamente quando um arquivo é criado em caminhos rastreados do Amazon S3. Para obter mais informações, consulte [Criar uma integração de eventos do S3 para copiar automaticamente arquivos de buckets do Amazon S3](loading-data-copy-job.md). | Deve ser usado quando um pipeline de ingestão de arquivos precisa ingerir dados automaticamente quando um arquivo é criado no Amazon S3. O Amazon Redshift monitora os arquivos ingeridos para evitar a duplicação de dados. Esse método requer configuração por proprietários de buckets do Amazon S3. | | Carregar diretamente de consultas de data lake | Crie tabelas externas para executar consultas de data lake em seus arquivos do Amazon S3 e, depois, execute o comando INSERT INTO para carregar os resultados de suas consultas de data lake em tabelas locais. Para obter mais informações, consulte [Tabelas externas para o Redshift Spectrum](c-spectrum-external-tables.md). | É possível usar qualquer um dos seguintes casos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/t_Loading_data.html) | | Outros métodos a serem considerados | | Ingestão de streaming | A ingestão de streaming oferece ingestão de dados de fluxo de baixa latência e alta velocidade do Amazon Kinesis Data Streams e do Amazon Managed Streaming para Apache Kafka em uma visão materializada provisionada pelo Amazon Redshift ou Amazon Redshift sem servidor. Para obter mais informações, consulte [Conceitos básicos da ingestão de streaming do Amazon Kinesis Data Streams](materialized-view-streaming-ingestion-getting-started.md) e [Conceitos básicos da ingestão de streaming de origens do Apache Kafka](materialized-view-streaming-ingestion-getting-started-MSK.md). | Deve ser considerado para casos de uso em que os dados são primeiro transmitidos para arquivos no Amazon S3 e depois carregados diretamente do Amazon S3. Se não for necessário manter os dados no Amazon S3, muitas vezes é possível transmiti-los diretamente para o Amazon Redshift. | | Executar consultas de data lake | Executar consultas diretamente de uma tabela do data lake em vez de ingerir o conteúdo da tabela em uma tabela local. Para obter mais informações, consulte [Amazon Redshift Spectrum](c-using-spectrum.md). | Deve ser usado quando o caso de uso não exige a performance de consultas de tabelas locais no Amazon Redshift. | | Carregamento em lote com o Editor de Consultas do Amazon Redshift v2 | É possível preparar e executar as workloads de ingestão de arquivos em lote visualmente no Editor de Consultas do Amazon Redshift v2. Para ter mais informações, consulte [Carregar dados do S3](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data) no *Guia de gerenciamento do Amazon Redshift*. | Deve ser usado quando você deseja que o Editor de Consultas v2 prepare declarações COPY e deseja uma ferramenta visual para simplificar o processo de preparação da declaração COPY. | | Carregar dados de um arquivo local com o Editor de Consultas do Amazon Redshift v2. | É possível fazer upload de arquivos diretamente da área de trabalho para as tabelas do Amazon Redshift sem a necessidade de carregar manualmente os arquivos no Amazon S3. Para ter mais informações, consulte [Carregar dados de uma configuração e fluxo de trabalho de arquivo local](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data-local) no *Guia de gerenciamento do Amazon Redshift*. | Deve ser usado quando você precisa carregar rapidamente arquivos do computador local para fins de consulta única. Com esse método, o Editor de Consultas do Amazon Redshift v2 armazena temporariamente o arquivo em um bucket do Amazon S3 de propriedade do cliente e executa um comando de cópia usando esse caminho do Amazon S3. | Um comando COPY é a forma mais eficiente para carregar uma tabela. Você também pode adicionar dados às suas tabelas usando comandos INSERT, embora isso seja muito menos eficiente que o uso de COPY. O comando COPY é capaz de ler de vários arquivos de dados ou vários fluxos de dados simultaneamente. O Amazon Redshift aloca a workload aos nós do Amazon Redshift e executa as operações de carregamento em paralelo, incluindo a classificação das linhas e a distribuição dos dados entre fatias do nó. **nota** As tabelas externas do Amazon Redshift Spectrum são de somente leitura. Não é possível COPY ou INSERT em uma tabela externa. Para acessar dados em outros recursos da AWS, o Amazon Redshift deve ter permissão para acessar esses recursos e para realizar as ações necessárias para acessar os dados. É possível usar o AWS Identity and Access Management (IAM) para limitar o acesso que os usuários têm aos recursos e aos dados do Amazon Redshift. Após o carregamento inicial de seus dados, se você adicionar, modificar ou excluir uma quantia significativa de dados, você deve executar um comando VACUUM para reorganizar seus dados e recuperar espaço após exclusões. Você também deve executar um comando ANALYZE para atualizar as estatísticas da tabela. **Topics** + [Carregar tabelas com o comando COPY](t_Loading_tables_with_the_COPY_command.md) + [Criar uma integração de eventos do S3 para copiar automaticamente arquivos de buckets do Amazon S3](loading-data-copy-job.md) + [Carregar tabelas com comandos DML](t_Updating_tables_with_DML_commands.md) + [Execução de uma cópia profunda](performing-a-deep-copy.md) + [Análise de tabelas](t_Analyzing_tables.md) + [Vacuum de tabelas](t_Reclaiming_storage_space202.md) + [Gerenciamento de operações de gravação simultâneas](c_Concurrent_writes.md) + [Tutorial: Carregar dados do Amazon S3](tutorial-loading-data.md) # Carregar tabelas com o comando COPY O comando COPY aproveita a arquitetura de processamento massivamente paralelo (MPP) do Amazon Redshift para ler e carregar dados em paralelo de arquivos no Amazon S3, de uma tabela do DynamoDB ou de saída de texto de um ou mais hosts remotos. Antes de conhecer todas as opções do comando COPY, recomendamos aprender as opções básicas para carregar dados do Amazon S3. O *Guia de conceitos básicos do Amazon Redshift* demonstra um uso simples do comando COPY para carregar dados do Amazon S3 usando um perfil padrão do IAM. Consulte [Etapa 4: Carregar dados do Amazon S3 para o Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) para ter detalhes. **nota** Recomendamos veementemente o uso do comando COPY para carregar grandes quantidades de dados. O uso de instruções INSERT individuais para povoar uma tabela pode ser proibitivamente lento. Como alternativa, se seus dados já existem em outras tabelas de banco de dados do Amazon Redshift, use INSERT INTO... SELECT ou CREATE TABLE AS para aprimorar a performance. Para obter informações, consulte [INSERT](r_INSERT_30.md) ou [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Para carregar dados de outro recurso da AWS, o Amazon Redshift deve ter permissão para acessar o recurso e realizar as ações necessárias. Por conceder ou revogar o privilégio para carregar dados em uma tabela usando um comando COPY, conceda ou revogue o privilégio INSERT. Seus dados precisam estar no formato adequado para serem carregados na tabela do Amazon Redshift. Esta seção apresenta as diretrizes para preparar e verificar seus dados antes do carregamento e para validar uma instrução COPY antes de executá-la. Para proteger as informações em seus arquivos, você pode criptografar os arquivos de dados antes de carregá-los em seu bucket do Amazon S3; O COPY irá descriptografar os dados enquanto executa o carregamento. Você também pode limitar o acesso que os usuários têm aos seus dados de carregamento fornecendo credenciais de segurança temporárias aos usuários. As credenciais de segurança temporárias oferecem segurança aprimorada, pois possuem vidas úteis curtas e não podem ser reutilizadas após o vencimento. O Amazon Redshift conta com recursos integrados ao COPY para carregar rapidamente dados descompactados e delimitados. Mas é possível compactar arquivos usando o gzip, o lzop ou o bzip2 para economizar tempo de carregamento de arquivos. Se as seguintes palavras-chave ocorrerem na consulta COPY, a divisão automática dos dados não compactados não é compatível: ESCAPE, REMOVEQUOTES e FIXEDWIDTH. Mas a palavra-chave CSV é compatível. Para ajudar a manter seus dados seguros em trânsito na Nuvem AWS, o Amazon Redshift usa SSL acelerado por hardware para se comunicar com o Amazon S3 ou o Amazon DynamoDB para operações de COPY, UNLOAD, backup e restauração. Ao carregar sua tabela diretamente de uma tabela do Amazon DynamoDB, você tem a opção de controlar a quantidade do throughput provisionado do Amazon DynamoDB que você consome. Você pode opcionalmente permitir que COPY analise seus dados de entrada e aplique automaticamente as codificações de compactação ideais em sua tabela como parte do processo de carregamento. **Topics** + [Credenciais e permissões de acesso](loading-data-access-permissions.md) + [Preparação de dados de entrada](t_preparing-input-data.md) + [Carregar dados do Amazon S3](t_Loading-data-from-S3.md) + [Carregar dados do Amazon EMR](loading-data-from-emr.md) + [Carregamento de dados de hosts remotos](loading-data-from-remote-hosts.md) + [Carregar dados de uma tabela do Amazon DynamoDB](t_Loading-data-from-dynamodb.md) + [Como verificar se os dados foram carregados corretamente](verifying-that-data-loaded-correctly.md) + [Validação de dados de entrada](t_Validating_input_files.md) + [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md) + [Otimização de armazenamento para tabelas estreitas](c_load_compression_hidden_cols.md) + [Carregamento de valores padrão de coluna](c_loading_default_values.md) + [Solução de problemas de carregamento de dados](t_Troubleshooting_load_errors.md) # Credenciais e permissões de acesso Para carregar ou descarregar dados usando outro recurso da AWS como Amazon S3, Amazon DynamoDB, Amazon EMR ou Amazon EC2, o Amazon Redshift deve ter permissão para acessar o recurso e realizar as ações necessárias para acessar os dados. Por exemplo, para carregar dados do Amazon S3, COPY deve ter acesso LIST para o bucket e acesso GET para os objetos do bucket. Para ter autorização para acessar um recurso, o Amazon Redshift deve ser autenticado. Você pode escolher o controle de acesso com base em função ou o controle de acesso com base em chave. Esta seção apresenta uma visão geral dos dois métodos. Para obter os detalhes completos e exemplos, consulte [Permissões para acessar outros recursos da AWS](copy-usage_notes-access-permissions.md). ## Controle de acesso com base em função Com o controle de acesso baseado em perfil, o Amazon Redshift assume temporariamente um perfil do AWS Identity and Access Management (IAM) em seu nome. Então, com base nas autorizações concedidas para o perfil, o Amazon Redshift pode acessar os recursos da AWS necessários. Recomendamos o uso de controle de acesso baseado em função porque ele fornece um controle mais seguro e refinado de acesso a recursos da AWS e dados confidenciais do usuário, além de proteger suas credenciais da AWS. Para usar o controle de acesso baseado em perfil, você deve primeiro criar um perfil do IAM usando o tipo de perfil de serviço do Amazon Redshift e, depois, anexar o perfil ao seu data warehouse. A função deve ter, pelo menos, as permissões listadas em [Permissões do IAM para COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Para ver as etapas de como criar um perfil do IAM e anexá-lo ao cluster, consulte “[Criar uma função do IAM para permitir que o cluster do Amazon Redshift acesse serviços da AWS](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html#authorizing-redshift-service-creating-an-iam-role)” no *Guia de gerenciamento de clusters do Amazon Redshift*. Você pode adicionar uma função a um cluster ou visualizar as funções associadas a um cluster usando o Console de Gerenciamento do Amazon Redshift, a CLI ou a API. Para obter mais informações, consulte “[Autorizar operações COPY, UNLOAD, CREATE EXTERNAL FUNCTION e CREATE EXTERNAL SCHEMA usando funções do IAM](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*. Quando você cria uma função do IAM, o IAM retorna um nome de recurso da Amazon (ARN) para a função. Para executar o comando COPY usando uma função do IAM, forneça o ARN da função usando o parâmetro IAM\$1ROLE ou o parâmetro CREDENTIALS. O seguinte exemplo de comando COPY usa o parâmetro IAM\$1ROLE com a função `MyRedshiftRole` para autenticação. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::12345678901:role/MyRedshiftRole'; ``` O usuário do AWS deve ter, pelo menos, as permissões listadas em [Permissões do IAM para COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). ## Controle de acesso com base em chave Com o controle de acesso baseado em chave, você fornece o ID da chave de acesso e a chave de acesso secreta para um usuário que está autorizado a acessar os recursos da AWS que contêm os dados.  **nota** É altamente recomendável usar uma função do IAM para autenticação em vez de fornecer um ID da chave de acesso de texto simples e uma chave de acesso secreta. Se você escolher o controle de acesso com base em chave, nunca use as credenciais de sua conta da AWS (raiz). Sempre crie um usuário do IAM e forneça o ID da chave de acesso e a chave de acesso secreta desse usuário. Para obter as etapas para criar um usuário do IAM, consulte [Criação de um usuário do IAM em sua conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). # Preparação de dados de entrada Se seus dados de entrada não forem compatíveis com as colunas da tabela que os receberão, o comando COPY falhará. Use as seguintes diretrizes para ajudar a garantir que seus dados de entrada sejam válidos: + Seus dados podem conter somente caracteres UTF-8 com até quatro bytes de comprimento. + Verifique que as strings CHAR e VARCHAR são mais longas que os comprimentos das colunas correspondentes. Strings VARCHAR são medidas em bytes, não caracteres, portanto, por exemplo, uma string de quatro caracteres chineses que ocupam quatro bytes cada requer uma coluna VARCHAR(16). + Caracteres multibyte podem ser usados somente com colunas VARCHAR. Verifique que os caracteres multibyte não tenham mais que quatro bytes de comprimento. + Verifique que os dados para colunas CHAR contenham somente caracteres de único byte. + Não inclua quaisquer caracteres ou sintaxe especial para indicar o último campo em um registro. Este campo pode ser um delimitador. + Se seus dados incluem terminais nulos, também chamados de NUL (UTF-8 0000) ou zero binário (0x000), você pode carregar esses caracteres como NULLS em colunas CHAR ou VARCHAR usando a opção NULL AS no comando COPY: `null as '\0'` ou `null as '\000'`. Se você não utilizar NULL AS, terminais nulos farão com que seu COPY falhe. + Se suas strings contêm caracteres especiais, tais como delimitadores e novas linhas inseridas, use a opção ESCAPE com o comando [COPY](r_COPY.md). + Verifique se todas as aspas simples e duplas correspondem adequadamente. + Verifique que as strings de ponto flutuante estejam no formato de ponto flutuante padrão, tal como 12.123, ou no formato exponencial, tal como 1.0E4. + Verifique que todas as strings de timestamp e data sigam as especificações para [Strings DATEFORMAT e TIMEFORMATExemplo](r_DATEFORMAT_and_TIMEFORMAT_strings.md). O formato de timestamp padrão é AAAA-MM-DD hh:mm:ss e formato de data padrão é AAAA-MM-DD. + Para obter mais informações sobre os limites e limitações dos tipos de dados individuais, consulte [Tipos de dados](c_Supported_data_types.md). Para obter mais informações sobre erros de caracteres multibyte, consulte . [Erros no carregamento de caracteres multibyte](multi-byte-character-load-errors.md) # Carregar dados do Amazon S3 O comando COPY utiliza a arquitetura de processamento paralelo em massa (MPP) do Amazon Redshift para ler e carregar dados em paralelo de um ou mais arquivos em um bucket do Amazon S3. Aproveite ao máximo a vantagem do processamento paralelo dividindo seus dados em vários arquivos, nos casos em que os arquivos são compactados. (Há exceções a essa regra. Elas são detalhados em [Carregar arquivos de dados](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-use-multiple-files.html).) Você também pode aproveitar ao máximo a vantagem do processamento paralelo ao configurar chaves de distribuição em suas tabelas. Para obter mais informações sobre chaves de distribuição, consulte [Distribuição de dados para otimização de consultas](t_Distributing_data.md). Os dados são carregados em uma tabela de destino, uma linha por linha. Os campos no arquivo de dados são correspondidos com as colunas da tabela em ordem, da esquerda para a direita. Os campos nos arquivos de dados podem ser de largura fixa ou delimitados por caracteres; o delimitador padrão é um pipe (\$1). Por padrão, todas as colunas da tabela são carregadas, mas você pode, opcionalmente, definir uma lista de colunas separadas por vírgula. Se uma tabela não foi incluída na lista de colunas especificada no comando COPY, ela será carregada com um valor padrão. Para obter mais informações, consulte [Carregamento de valores padrão de coluna](c_loading_default_values.md). **Topics** + [Carregar dados de arquivos compactados e não compactados](t_splitting-data-files.md) + [Carregar arquivos no Amazon S3 para usar com COPY](t_uploading-data-to-S3.md) + [Usando o comando COPY para carregar do Amazon S3](t_loading-tables-from-s3.md) # Carregar dados de arquivos compactados e não compactados Ao carregar dados compactados, recomendamos dividir os dados de cada tabela em vários arquivos. Quando você carrega dados descompactados e delimitados, o comando COPY usa processamento paralelo em massa (MPP) e intervalos de varredura para carregar dados de arquivos grandes em um bucket do Amazon S3. ## Carregar dados de vários arquivos compactados Caso você tenha dados compactados, recomendamos dividir os dados de cada tabela em vários arquivos. O comando COPY pode carregar dados a partir de vários arquivos em paralelo. Você pode carregar vários arquivos especificando um prefixo comum ou *prefixo de chave* para o conjunto ou listando explicitamente os arquivos em um arquivo manifesto. Divida seus dados em arquivos de modo que o número de arquivos seja um múltiplo do número de fatias em seu cluster. Assim, o Amazon Redshift pode dividir os dados igualmente entre as fatias. O número de fatias por nó depende do tamanho do nó do cluster. Por exemplo, cada nó de computação dc2.large tem duas fatias e cada nó de computação dc2.8xlarge tem 16 fatias. Para obter mais informações sobre o número de fatias que cada tamanho de nó possui, consulte “[Clusters e nós no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes)” no *Guia de gerenciamento de clusters do Amazon Redshift*. Todos os nós participam da execução de consultas paralelas, trabalhando nos dados que são distribuídos da maneira mais uniforme possível pelas fatias. Caso tenha um cluster com dois nós dc2.large, você poderá dividir os dados em quatro arquivos ou em um múltiplo de quatro. O Amazon Redshift não leva em conta o tamanho do arquivo ao dividir o workload. Desse modo, você precisa garantir que os arquivos tenham aproximadamente o mesmo tamanho, de 1 MB a 1 GB, após a compactação. Para usar prefixos de objeto para identificar arquivos de carregamento, nomeie cada arquivo com um prefixo comum. Por exemplo, você poderá dividir o arquivo `venue.txt` em quatro arquivos, do modo a seguir. ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` Ao colocar vários arquivos em uma pasta de seu bucket, você pode especificar o nome da pasta como o prefixo, e o COPY carregará todos os arquivos na pasta. Se você explicitamente listar os arquivos a serem carregador usando um arquivo manifesto, os arquivos podem residir em buckets ou pastas diferentes. Para obter mais informações sobre arquivos manifesto, consulte [Uso de um manifesto para especificar arquivos de dados](r_COPY_command_examples.md#copy-command-examples-manifest). ## Carregar dados de arquivos descompactados e delimitados Ao carregar dados delimitados e descompactados, o comando COPY usa a arquitetura de processamento paralelo em massa (MPP) no Amazon Redshift. O Amazon Redshift usa automaticamente fatias que trabalham em paralelo para carregar intervalos de dados de um arquivo grande para um bucket do Amazon S3. Para que o carregamento paralelo ocorra, o arquivo deve ser delimitado. Por exemplo, delimitado por barras verticais. O carregamento de dados automático e paralelo com o comando COPY também está disponível para arquivos CSV. Você também pode utilizar o processamento paralelo configurando chaves de distribuição em suas tabelas. Para obter mais informações sobre chaves de distribuição, consulte [Distribuição de dados para otimização de consultas](t_Distributing_data.md). O carregamento paralelo automático não é compatível quando a consulta COPY inclui uma das seguintes palavras-chave: ESCAPE, REMOVEQUOTES e FIXEDWIDTH. Os dados dos arquivos são carregados em uma tabela de destino, uma linha por linha da tabela. Os campos no arquivo de dados são correspondidos com as colunas da tabela em ordem, da esquerda para a direita. Os campos nos arquivos de dados podem ser de largura fixa ou delimitados por caracteres; o delimitador padrão é um pipe (\$1). Por padrão, todas as colunas da tabela são carregadas, mas você pode, opcionalmente, definir uma lista de colunas separadas por vírgula. Se a tabela não estiver incluída na lista de colunas especificada no comando COPY, ela será carregada com um valor padrão. Para obter mais informações, consulte [Carregamento de valores padrão de coluna](c_loading_default_values.md). Siga este processo geral para carregar dados do Amazon S3 quando os dados são descompactados e delimitados: 1. Faça upload de seus arquivos para o Amazon S3. 1. Execute um comando COPY para carregar a tabela. 1. Verifique se os dados foram carregados corretamente. Para obter exemplos de comandos COPY, consulte [Exemplos de COPY](r_COPY_command_examples.md). Para obter informações sobre dados carregados no Amazon Redshift, verifique as tabelas de sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) e [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md). Para obter mais informações sobre nós e as fatias contidas em cada um deles, consulte “[Clusters e nós no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes)” no *Guia de gerenciamento de clusters do Amazon Redshift*. # Carregar arquivos no Amazon S3 para usar com COPY Há algumas abordagens a serem adotadas ao carregar arquivos de texto para o Amazon S3: + Se você tiver arquivos compactados, recomendamos dividir arquivos grandes para aproveitar a vantagem do processamento paralelo no Amazon Redshift. + No entanto, o COPY divide automaticamente dados de arquivos grandes, descompactados e delimitados por texto para facilitar o paralelismo e distribuir efetivamente dados de arquivos grandes. Crie um bucket do Amazon S3 para armazenar seus arquivos de dados e, em seguida, carregue os arquivos de dados para o bucket. Para obter informações sobre a criação de buckets e carregamento de arquivos, consulte [Trabalhar com buckets do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) no *Guia do usuário do Amazon Simple Storage Service*. **Importante** O bucket do Amazon S3 que contém os arquivos de dados deve ser criado na mesma região da AWS do seu cluster, a menos que você use a opção [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar a região em que o bucket do Amazon S3 está localizado. Certifique-se de que os intervalos de IP do S3 sejam adicionados à sua lista de permissões. Para saber mais sobre os intervalos de IP do S3 necessários, consulte [ Isolamento de rede](https://docs.aws.amazon.com//redshift/latest/mgmt/security-network-isolation.html#network-isolation). Você pode criar um bucket do Amazon S3 em uma região específica selecionando a região ao criar o bucket usando o console do Amazon S3 ou especificando um endpoint ao criar o bucket usando a API ou CLI do Amazon S3. Após o carregamento de dados, verifique se os arquivos corretos estão presentes no Amazon S3. **Topics** + [Gerenciamento da consistência de dados](managing-data-consistency.md) + [Carregamento de dados criptografados para Amazon S3](t_uploading-encrypted-data.md) + [Verificação da presença dos arquivos corretos no bucket](verifying-that-correct-files-are-present.md) # Gerenciamento da consistência de dados O Amazon S3 oferece uma forte consistência de leitura após gravação para operações COPY, UNLOAD, INSERT (tabela externa), CREATE EXTERNAL TABLE AS e Amazon Redshift Spectrum em buckets do Amazon S3 em todas as regiões da AWS. Além disso, as operações de leitura no Amazon S3 Select, lista de controle de acesso do Amazon S3, Amazon S3 Object Tags e metadados de objeto (por exemplo, objeto HEAD) são fortemente consistentes. Para obter mais informações sobre consistência de dados, consulte [Modelo de consistência de dados do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Introduction.html#ConsistencyModel) no *Guia do usuário do Amazon Simple Storage Service*. # Carregamento de dados criptografados para Amazon S3 O Amazon S3 oferece suporte para criptografia do lado do servidor e criptografia do lado do cliente. Este tópico discute as diferenças entre a criptografia do lado do servidor e do lado do cliente e descreve as etapas para usar a criptografia do lado do cliente com o Amazon Redshift. A criptografia do lado do servidor é transparente para o Amazon Redshift. ## Criptografia do lado do servidor A criptografia do lado do servidor é a criptografia de dados em repouso, ou seja, o Amazon S3 criptografa seus dados à medida que os carrega e os descriptografa para você quando você os acessa. Quando você carrega tabelas usando um comando COPY, não há diferença na maneira como você carrega de objetos criptografados ou não criptografados do lado do servidor no Amazon S3. Para obter mais informações sobre a criptografia do lado do servidor, consulte [Usar criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) no *Guia do usuário do Amazon Simple Storage Service*. ## Criptografia do lado do cliente Na criptografia no lado do cliente, seu aplicativo cliente gerencia a criptografia de seus dados, chaves de criptografia e ferramentas relacionadas. Você pode fazer upload de dados para um bucket do Amazon S3 usando criptografia do lado do cliente e, em seguida, carregar os dados usando o comando COPY com a opção ENCRYPTED e uma chave de criptografia privada para fornecer maior segurança. Você criptografa seus dados usando criptografia de envelope. Com *criptografia de envelope*, seu aplicativo cuida de toda criptografia exclusivamente. Suas chaves de criptografia privadas e seus dados não criptografados nunca são enviados para a AWS, por isso é muito importante que você gerencie com segurança suas chaves de criptografia. Se você perder suas chaves de criptografia, não poderá descriptografar seus dados e não poderá recuperar suas chaves de criptografia da AWS. A criptografia de envelope alia a performance da criptografia simétrica rápida ao mesmo tempo com a maior segurança que o gerenciamento com chaves assimétricas oferece. Uma chave simétrica de uso único (a chave simétrica de envelope) é gerada por seu cliente de criptografia Amazon S3 para criptografar seus dados. Portanto, essa chave é criptografada por sua chave raiz e armazenada com seus dados no Amazon S3. Quando o Amazon Redshift acessa seus dados durante um carregamento, a chave simétrica criptografada é recuperada e descriptografada com sua chave real e, em seguida, os dados são descriptografados. Para trabalhar com dados criptografados do lado do cliente do Amazon S3 no Amazon Redshift, siga as etapas descritas em [Proteger dados usando criptografia do lado do cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) no *Guia do usuário do Amazon Simple Storage Service*, com os demais requisitos que você usa: + **Criptografia simétrica ** A classe `AmazonS3EncryptionClient` do SDK for Java da AWS usa criptografia de envelope, descrita anteriormente, que é baseada na criptografia de chave simétrica. Use esta classe para criar um cliente Amazon S3 para carregar dados criptografados do lado do cliente. + **Uma chave mestra simétrica AES de 256 bits:** uma chave primária criptografa a chave de envelope. Você transmite a chave raiz à sua instância da classe `AmazonS3EncryptionClient`. Salve esta chave, pois você precisará dela para copiar dados no Amazon Redshift. + **Metadados de objeto para armazenar chave de envelope criptografada** – Por padrão, o Amazon S3 armazena a chave de envelope como metadados de objeto para a classe `AmazonS3EncryptionClient`. A chave de envelope criptografada que é armazenada como metadados de objeto é usada durante o processo de descriptografia. **nota** Se você receber uma mensagem de erro de criptografia quando usar a API de criptografia pela primeira vez, sua versão do JDK pode ter um arquivo de políticas de jurisdição JCE (Java Cryptography Extension) que limita o tamanho máximo da chave para transformações de criptografia e descriptografia para 128 bits. Para obter informações sobre como resolver esse problema, acesse [Especificar a criptografia do lado do cliente usando o AWS SDK para Java](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryptionUpload.html) no *Guia do usuário do Amazon Simple Storage Service*. Para obter informações sobre como carregar arquivos criptografados do lado do cliente em suas tabelas do Amazon Redshift usando o comando COPY, consulte [Carregar arquivos de dados criptografados do Amazon S3](c_loading-encrypted-files.md). ## Exemplo: upload de dados criptografados no lado do cliente Para obter um exemplo de como usar o AWS SDK para Java para carregar dados criptografados do lado do cliente, acesse [Proteger dados usando criptografia do lado do cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/encrypt-client-side-symmetric-master-key.html) no *Guia do usuário do Amazon Simple Storage Service*. A segunda opção mostra as escolhas que você deve fazer durante a criptografia do lado do cliente para que os dados possam ser carregados no Amazon Redshift. Especificamente, o exemplo mostra o uso de metadados de objeto para armazenar a chave de envelope criptografada e o uso de uma chave raiz simétrica AES de 256 bits. Este exemplo fornece código de exemplo usando o AWS SDK para Java para criar uma chave raiz simétrica AES de 256 bits e salvá-la em um arquivo. Em seguida, o exemplo faz upload de um objeto no Amazon S3 usando um cliente de criptografia do S3 que inicialmente criptografa dados de amostra no lado do cliente. O exemplo também baixa objeto e verifica se os dados são os mesmos. # Verificação da presença dos arquivos corretos no bucket Depois de carregar seus arquivos para o bucket do Amazon S3, recomendamos listar o conteúdo do bucket para verificar se todos os arquivos corretos estão presentes e se nenhum arquivo indesejado está presente. Por exemplo, se o bucket `amzn-s3-demo-bucket` tiver um arquivo chamado `venue.txt.back`, esse arquivo será carregado, talvez involuntariamente, pelo seguinte comando: ``` COPY venue FROM 's3://amzn-s3-demo-bucket/venue' … ; ``` Se você quiser controlar especificamente quais arquivos são carregados, você pode usar um arquivo manifesto para listar explicitamente os arquivos de dados. Para obter mais informações sobre o uso de um arquivo manifesto, consulte a opção [copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file) para o comando COPY e [Uso de um manifesto para especificar arquivos de dados](r_COPY_command_examples.md#copy-command-examples-manifest) nos exemplos de COPY. Para obter mais informações sobre como listar o conteúdo do bucket, consulte [Listagem de chaves de objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ListingKeysUsingAPIs.html) no *Guia do desenvolvedor do Amazon S3*. # Usando o comando COPY para carregar do Amazon S3 Use o comando [COPY](r_COPY.md) para carregar uma tabela em paralelo a partir de arquivos de dados no Amazon S3. Você pode especificar os arquivos a serem carregados usando um prefixo de objeto do Amazon S3 ou usando um arquivo manifesto. A sintaxe para especificar os arquivos a serem carregados usando um prefixo é a seguinte: ``` COPY FROM 's3:///' authorization; ``` O arquivo manifesto é um arquivo em formato JSON que lista os arquivos de dados a serem carregados. A sintaxe para especificar os arquivos a serem carregados usando um arquivo manifesto é a seguinte: ``` COPY FROM 's3:///' authorization MANIFEST; ``` A tabela a ser carregada já deve existir no banco de dados. Para obter informações sobre como criar uma tabela, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md) na referência do SQL. Os valores para *autorização* fornecem a autorização da AWS de que o Amazon Redshift precisa para acessar objetos do Amazon S3. Para obter informações sobre as permissões necessárias, consulte [Permissões do IAM para COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). O método preferido de autenticação é especificar o parâmetro IAM\$1ROLE e fornecer o nome de recurso da Amazon (ARN) para uma função do IAM com as permissões necessárias. Para obter mais informações, consulte [Controle de acesso com base em função](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based) . Para autenticação usando o parâmetro IAM\$1ROLE, substitua ** e ** conforme exibido na sintaxe a seguir. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` O seguinte exemplo mostra a autenticação usando uma função do IAM. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Para obter mais informações sobre outras opções de autorização, consulte [Parâmetros de autorização](copy-parameters-authorization.md) Se você quiser validar seus dados sem realmente carregar a tabela, use a opção NOLOAD com o comando [COPY](r_COPY.md). O seguinte exemplo mostra as primeiras linhas de dados delimitados por pipe em um arquivo chamado `venue.txt`. ``` 1|Toyota Park|Bridgeview|IL|0 2|Columbus Crew Stadium|Columbus|OH|0 3|RFK Stadium|Washington|DC|0 ``` Antes de enviar o arquivo para o Amazon S3, divida o arquivo em vários arquivos para que o comando COPY possa carregá-lo usando o processamento paralelo. O número de arquivos deve ser um múltiplo do número de fatias em seu cluster. Divida seus arquivos de dados de carregamento para que os arquivos tenham o mesmo tamanho aproximado, entre 1 MB e 1 GB após a compactação. Para obter mais informações, consulte [Carregar dados de arquivos compactados e não compactados](t_splitting-data-files.md). Por exemplo, o arquivo `venue.txt` pode ser dividido em quatro arquivos, da seguinte forma: ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` O seguinte comando COPY carrega a tabela VENUE usando os dados delimitados por pipe nos arquivos de dados com o prefixo “local” no bucket do Amazon S3 `amzn-s3-demo-bucket`. **nota** O bucket `amzn-s3-demo-bucket` do Amazon S3 nos exemplos a seguir não existe. Para uma amostra dos comandos COPY que usam dados reais em um bucket existente do Amazon S3, consulte [Carregar dados de amostra](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 nenhum objeto Amazon S3 com o prefixo “local” existir, o carregamento falhará. **Topics** + [Uso de um manifesto para especificar arquivos de dados](loading-data-files-using-manifest.md) + [Carregar arquivos de dados compactados do Amazon S3](t_loading-gzip-compressed-data-files-from-S3.md) + [Carregar dados de largura fixa do Amazon S3](t_loading_fixed_width_data.md) + [Carregar dados multibyte do Amazon S3](t_loading_unicode_data.md) + [Carregar arquivos de dados criptografados do Amazon S3](c_loading-encrypted-files.md) # Uso de um manifesto para especificar arquivos de dados Você pode usar um manifesto para garantir que o comando COPY carregue todos os arquivos necessários, e somente os arquivos necessários, para um carregamento de dados. Você pode usar um manifesto para carregar vários arquivos de buckets diferentes ou arquivos que não compartilham o mesmo prefixo. Em vez de fornecer um caminho de objeto para o comando COPY, você fornece o nome de um arquivo de texto em formato JSON que lista explicitamente os arquivos a serem carregados. O URL no manifesto deve especificar o nome de bucket e o caminho de objeto completo para o arquivo, e não apenas um prefixo. Para obter mais informações sobre arquivos manifesto, consulte o exemplo de COPY [Usar um manifesto para especificar arquivos de dados](r_COPY_command_examples.md#copy-command-examples-manifest). O seguinte exemplo mostra o JSON para carregar arquivos de diferentes buckets e com nomes de arquivos que começam com carimbos de 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} ] } ``` O sinalizador opcional `mandatory` especifica se COPY deve retornar um erro se o arquivo não for localizado. O padrão de `mandatory` é `false`. Independentemente de qualquer configuração obrigatória, COPY será encerrado se nenhum arquivo for encontrado. O exemplo a seguir executa o comando COPY com o manifesto do exemplo anterior, chamado `cust.manifest`. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/cust.manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MANIFEST; ``` ## Uso de um manifesto criado por UNLOAD Um manifesto criado por uma operação [UNLOAD](r_UNLOAD.md) usando o parâmetro MANIFEST pode ter chaves que não são necessárias para a operação COPY. Por exemplo, o manifesto `UNLOAD` a seguir inclui uma chave `meta` que é necessária para uma tabela externa do Amazon Redshift Spectrum e para o carregamento de arquivos de dados em um formato de arquivo `ORC` ou `Parquet`. A chave `meta` contém uma chave `content_length` com um valor que é o tamanho real do arquivo em bytes. A operação COPY requer somente a chave `url` uma chave `mandatory` opcional. ``` { "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 }} ] } ``` Para obter mais informações sobre arquivos manifesto, consulte [Uso de um manifesto para especificar arquivos de dados](r_COPY_command_examples.md#copy-command-examples-manifest). # Carregar arquivos de dados compactados do Amazon S3 Para carregar arquivos de dados compactados usando gzip, lzop, ou bzip2, inclua a opção correspondente: GZIP, LZOP ou BZIP2. Por exemplo, o seguinte comando carrega a partir de arquivos que foram compactados usando lzop. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/customer.lzo' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' LZOP; ``` **nota** Quando você compacta um arquivo de dados com compactação lzop e usa a opção *--filter*, não é possível usar o comando COPY. # Carregar dados de largura fixa do Amazon S3 Arquivos de dados de largura fixa têm comprimentos uniformes para cada coluna de dados. Cada campo em um arquivo de dados de largura fixa tem exatamente o mesmo comprimento e posição. Para dados de caracteres (CHAR e VARCHAR) em um arquivo de dados de largura fixa, você deve incluir espaços em branco iniciais ou finais como espaços reservados para manter a largura uniforme. Para números inteiros, você deve usar zeros iniciais como espaços reservados. Um arquivo de dados de largura fixa não tem qualquer delimitador para separar colunas. Para carregar um arquivo de dados de largura fixa em uma tabela existente, USE o parâmetro FIXEDWIDTH no comando COPY. As especificações de sua tabela devem corresponder ao valor de fixedwidth\$1spec para que os dados sejam carregados corretamente. Para carregar dados de largura fixa de um arquivo para uma tabela, emita o seguinte comando: ``` COPY table_name FROM 's3://amzn-s3-demo-bucket/prefix' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' FIXEDWIDTH 'fixedwidth_spec'; ``` O parâmetro *fixedwidth\$1spec* é uma string que contém um identificador para cada coluna e a largura de cada coluna, separados por um sinal de dois pontos. Os pares de **column:width** são delimitados por vírgulas. O identificador pode ser o que você escolher: números, letras ou uma combinação dos dois. O identificador não tem qualquer relação com a própria tabela, portanto a especificação deve conter as colunas na mesma ordem que a tabela. Os dois exemplos a seguir mostram a mesma especificação, a primeira usando identificadores numéricos e a segunda usando identificadores de string: ``` '0:3,1:25,2:12,3:2,4:6' ``` ``` 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6' ``` O seguinte exemplo exibe dados de amostra de largura fixa que poderiam ser carregados na tabela VENUE usando as especificações precedentes: ``` 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 ``` O seguinte comando COPY carrega este conjunto de dados na tabela 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'; ``` # Carregar dados multibyte do Amazon S3 Se seus dados incluem caracteres multibyte não ASCII (tal como caracteres chineses ou cirílicos), você deve carregar os dados em colunas VARCHAR. O tipo de dados VARCHAR é compatível com caracteres UTF-8 de quatro bytes, mas o tipo de dados CHAR aceita apenas caracteres ASCII de único byte. Você não pode carregar caracteres de cinco bytes ou mais nas tabelas do Amazon Redshift. Para obter mais informações sobre CHAR e VARCHAR, consulte [Tipos de dados](c_Supported_data_types.md). Para verificar qual codificação um arquivo de entrada usa, use o comando * `file` * do Linux: ``` $ file ordersdata.txt ordersdata.txt: ASCII English text $ file uni_ordersdata.dat uni_ordersdata.dat: UTF-8 Unicode text ``` # Carregar arquivos de dados criptografados do Amazon S3 Você pode usar o comando COPY para carregar arquivos de dados que foram carregados no Amazon S3 usando criptografia do lado do servidor, criptografia do lado do cliente ou ambos. O comando COPY é compatível com os seguintes tipos de criptografia do Amazon S3: + Criptografia do lado do servidor com chaves gerenciadas pelo Amazon S3 (SSE-S3) + Criptografia do lado do servidor com o AWS KMS keys (SSE-KMS) + Criptografia do lado do cliente usando uma chave raiz simétrica do lado do cliente O comando COPY não é compatível com os seguintes tipos de criptografia do Amazon S3: + Criptografia do lado do servidor com chaves fornecidas pelo cliente (SSE-C) + Criptografia do lado do cliente usando uma AWS KMS key + Criptografia do lado do cliente usando uma chave raiz assimétrica fornecida pelo cliente Para obter mais informações sobre a criptografia do Amazon S3, consulte [ Proteger dados usando criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) e [Proteger dados usando criptografia do lado do cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) no Guia do usuário do Amazon Simple Storage Service. O comando [UNLOAD](r_UNLOAD.md) criptografa arquivos automaticamente usando SSE-S3. Você também pode descarregar usando SSE-KMS ou criptografia do lado do cliente com uma chave simétrica gerenciada pelo cliente. Para obter mais informações, consulte . [Descarregamento de arquivos de dados criptografados](t_unloading_encrypted_files.md) O comando COPY automaticamente reconhece e carrega arquivos de dados criptografados usando SSE-S3 e SSE-KMS. Você pode carregar arquivos criptografados usando uma chave raiz simétrica do lado do cliente, especificando a opção ENCRYPTED e fornecendo a chave-valor. Para obter mais informações, consulte [Carregamento de dados criptografados para Amazon S3](t_uploading-encrypted-data.md). Para carregar arquivos de dados criptografados do lado do cliente, forneça a chave-valor raiz usando o parâmetro MASTER\$1SYMMETRIC\$1KEY e inclua a opção ENCRYPTED. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MASTER_SYMMETRIC_KEY '' ENCRYPTED DELIMITER '|'; ``` Para carregar arquivos de dados criptografados que estão compactados por gzip, lzop ou bzip2, inclua a opção GZIP, LZOP ou BZIP2 com a chave-valor raiz e a opção 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; ``` # Carregar dados do Amazon EMR Você pode usar o comando COPY para carregar dados em paralelo de um cluster do Amazon EMR configurado para gravar arquivos de texto no Sistema de Arquivos Distribuído do Hadoop (HDFS) do cluster na forma de arquivos de largura fixa, arquivos delimitados por caracteres, arquivos CSV ou com formato JSON. ## Processo de carregamento de dados do Amazon EMR Esta seção o orienta no processo de carregamento de dados de um cluster Amazon EMR. As seções a seguir fornecem os detalhes de que você precisa para realizar cada etapa. + **[Etapa 1: Configurar permissões do IAM](#load-from-emr-steps-configure-iam)** Os usuários que criam o cluster do Amazon EMR e executam o comando COPY do Amazon Redshift devem ter as permissões necessárias. + **[Etapa 2: Criar um cluster do Amazon EMR](#load-from-emr-steps-create-cluster)** Configure o cluster para enviar arquivos de texto para o Hadoop Distributed File System (HDFS). Você precisará do ID do cluster do Amazon EMR e do DNS público principal do cluster (o endpoint da instância do Amazon EC2 que hospeda o cluster). + **[Etapa 3: Recuperar a chave pública do cluster do Amazon Redshift e os endereços IP do nó do cluster](#load-from-emr-steps-retrieve-key-and-ips)** A chave pública permite que os nós de cluster do Amazon Redshift estabeleçam conexões SSH com os hosts. Você usará o endereço IP de cada nó do cluster para configurar os grupos de segurança do host para permitir o acesso de seu cluster Amazon Redshift usando esses endereços IP. + **[Etapa 4: Adicionar a chave pública do cluster do Amazon Redshift a cada arquivo de chaves autorizadas do host do Amazon EC2](#load-from-emr-steps-add-key-to-host)** Você adiciona a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host para que o host reconheça o cluster do Amazon Redshift e aceite a conexão SSH. + **[Etapa 5: Configurar os hosts para aceitar todos os endereços IP do cluster do Amazon Redshift](#load-from-emr-steps-configure-security-groups)** Modifique os grupos de segurança da instância do Amazon EMR para adicionar regras de entrada para aceitar os endereços IP do Amazon Redshift. + **[Etapa 6: Executar o comando COPY para carregar os dados](#load-from-emr-steps-run-copy)** De um banco de dados do Amazon Redshift, execute o comando COPY para carregar os dados em uma tabela do Amazon Redshift. ## Etapa 1: Configurar permissões do IAM Os usuários que criam o cluster do Amazon EMR e executam o comando COPY do Amazon Redshift devem ter as permissões necessárias. **Para configurar permissões do IAM** 1. Adicione as permissões a seguir para o usuário que criará o cluster do Amazon EMR. ``` ec2:DescribeSecurityGroups ec2:RevokeSecurityGroupIngress ec2:AuthorizeSecurityGroupIngress redshift:DescribeClusters ``` 1. Adicione a seguinte permissão para o usuário ou perfil do IAM que executará o comando COPY. ``` elasticmapreduce:ListInstances ``` 1. Adicione a permissão a seguir à função do IAM do cluster do Amazon EMR. ``` redshift:DescribeClusters ``` ## Etapa 2: Criar um cluster do Amazon EMR O comando COPY carrega dados de arquivos no Amazon EMR Hadoop Distributed File System (HDFS). Ao criar o cluster Amazon EMR, configure-o para enviar arquivos de dados para o HDFS do cluster. **Para criar um cluster do Amazon EMR** 1. Crie um cluster do Amazon EMR na região da AWS como cluster do Amazon Redshift. Se o cluster do Amazon Redshift estiver em uma VPC, o cluster do Amazon EMR deverá estar no mesmo grupo de VPC. Se o cluster do Amazon Redshift usa o modo EC2-Classic (ou seja, não está em um VPC), o cluster do Amazon EMR também deve usar o modo EC2-Classic. Para obter mais informações, consulte “[Gerenciamento de clusters em uma VPC](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*. 1. Configure o cluster para enviar arquivos de dados para o HDFS do cluster. Os nomes de arquivos do HDFS não devem conter asteriscos (\$1) ou pontos de interrogação (?). **Importante** Os nomes de arquivos não devem conter asteriscos ( \$1 ) ou pontos de interrogação ( ? ). 1. Especifique **No** (Não) para a opção **Auto-terminate** (Terminar automaticamente) na configuração de cluster do Amazon EMR para que o cluster permaneça disponível enquanto o comando COPY for executado. **Importante** Se um dos arquivos de dados for alterado ou excluído antes de COPY ser concluído, você poderá ter resultados inesperados ou a operação COPY poderá falhar. 1. Observe o ID do cluster e o DNS público primário (o endpoint da instância do Amazon EC2 que hospeda o cluster). Você usará essas informações em etapas subsequentes. ## Etapa 3: Recuperar a chave pública do cluster do Amazon Redshift e os endereços IP do nó do cluster Você usará o endereço IP de cada nó do cluster para configurar os grupos de segurança do host para permitir o acesso de seu cluster Amazon Redshift usando esses endereços IP. **Para recuperar a chave pública do cluster do Amazon Redshift e os endereços IP do nó do cluster para o seu cluster usando o console** 1. Acesse o Console de Gerenciamento do Amazon Redshift. 1. No painel de navegação, selecione o link **Clusters**. 1. Selecione seu cluster na lista. 1. Localize o grupo **Configurações de ingestão do SSH**. Observe a **Chave pública do cluster** e **Endereços IP dos nós**. Você vai usá-los em etapas subsequentes. ![\[Captura de tela do grupo Configurações de ingestão SSH mostrando a chave pública do cluster e os endereços IP do nó.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/copy-from-ssh-console-2.png) Você usará os endereços IP privados na Etapa 3 para configurar o host do Amazon EC2 para aceitar a conexão do Amazon Redshift. Para recuperar a chave pública do cluster e os endereços IP do nó do cluster para seu cluster usando a CLI do Amazon Redshift, execute o comando describe-clusters. Por exemplo: ``` aws redshift describe-clusters --cluster-identifier ``` A resposta incluirá um valor de ClusterPublicKey e a lista de endereços IP privados e públicos, semelhante ao seguinte: ``` { "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", ... ... } ``` Para recuperar a chave pública do cluster e os endereços IP do nó do cluster para o seu cluster usando a API do Amazon Redshift, use a ação `DescribeClusters`. Para obter mais informações, consulte [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) no *Guia de CLI do Amazon Redshift* ou [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) no Guia de API do Amazon Redshift. ## Etapa 4: Adicionar a chave pública do cluster do Amazon Redshift a cada arquivo de chaves autorizadas do host do Amazon EC2 Você adiciona a chave pública do cluster ao arquivo de chaves autorizadas de cada host para todos os nós do cluster do Amazon EMR para que os hosts reconheçam o Amazon Redshift e aceitem a conexão SSH. **Para adicionar a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host** 1. Acesse o host usando uma conexão SSH. Para obter informações sobre como se conectar a uma instância usando SSH, consulte [Conectar-se à instância do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) no *Manual do usuário do Amazon EC2*. 1. Copie a chave pública do Amazon Redshift do console ou do texto de resposta da CLI. 1. Copie e cole os conteúdos da chave pública no arquivo `/home//.ssh/authorized_keys` no host. Inclua a string completa com o prefixo “`ssh-rsa`” e o sufixo “`Amazon-Redshift`”. Por exemplo: ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Etapa 5: Configurar os hosts para aceitar todos os endereços IP do cluster do Amazon Redshift Para permitir o tráfego de entrada para as instâncias do host, edite o grupo de segurança e adicione uma regra de entrada para cada nó de cluster do Amazon Redshift. Para **Tipo**, selecione SSH com protocolo TCP na porta 22. Em **Source** (Fonte), insira os endereços IP privados do nó do cluster do Amazon Redshift que você recuperou em [Etapa 3: Recuperar a chave pública do cluster do Amazon Redshift e os endereços IP do nó do cluster](#load-from-emr-steps-retrieve-key-and-ips). Para obter informações sobre como adicionar regras a um grupo de segurança do Amazon EC2, consulte [Autorizar tráfego de entrada para as instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) no *Manual do usuário do Amazon EC2*. ## Etapa 6: Executar o comando COPY para carregar os dados Execute um comando [COPY](r_COPY.md) para se conectar ao cluster do Amazon EMR e carregar os dados em uma tabela do Amazon Redshift. O cluster do Amazon EMR deve continuar em execução até que o comando COPY seja concluído. Por exemplo, não configure o encerramento automático do cluster. **Importante** Se um dos arquivos de dados for alterado ou excluído antes de COPY ser concluído, você poderá ter resultados inesperados ou a operação COPY poderá falhar. No comando COPY, especifique o ID do cluster Amazon EMR e o caminho do arquivo HDFS e o nome do arquivo. ``` COPY sales FROM 'emr://myemrclusterid/myoutput/part*' CREDENTIALS IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Você pode usar caracteres curinga asterisco ( `*` ) e ponto de interrogação ( `?` ) como parte do argumento do nome do arquivo. Por exemplo, `part*` carrega os arquivos `part-0000`, `part-0001` e assim por diante. Se você especificar somente um nome de pasta, COPY tentará carregar todos os arquivos na pasta. **Importante** Se você usar caracteres curinga ou usar somente o nome da pasta, certifique-se de que nenhum arquivo indesejado seja carregado ou o comando COPY falhará. Por exemplo, alguns processos podem gravar um arquivo de log na pasta de saída. # Carregamento de dados de hosts remotos Você pode usar o comando COPY para carregar dados em paralelo de um ou mais hosts remotos, como instâncias do Amazon EC2 ou outros computadores. O COPY se conecta aos hosts remotos usando SSH e executa comandos nos hosts remotos para gerar a saída de texto. O host remoto pode ser uma instância do Amazon EC2 Linux ou outro computador Unix ou Linux configurado para aceitar conexões SSH. Este guia assume que seu host remoto é uma instância do Amazon EC2. Quando o procedimento for diferente para outro computador, o guia indicará a diferença. O Amazon Redshift pode conectar-se a vários hosts e abrir várias conexões SSH para cada host. O Amazon Redshifts envia um comando exclusivo por meio de cada conexão a fim de gerar saída de texto para a saída padrão do host, que o Amazon Redshift lê como faria com um arquivo de texto. ## Antes de começar Antes de começar, você deve ter o seguinte: + Uma ou mais máquinas host, como instâncias do Amazon EC2, às quais você pode se conectar usando SSH. + Fontes de dados nos hosts. Você fornecerá comandos que o cluster do Amazon Redshift executará nos hosts para gerar a saída de texto. Depois que o cluster se conecta a um host, o comando COPY executa os comandos, lê o texto da saída padrão dos hosts e carrega os dados em paralelo em uma tabela do Amazon Redshift. A saída de texto deve estar em um formulário que o comando COPY possa ingerir. Para obter mais informações, consulte . [Preparação de dados de entrada](t_preparing-input-data.md) + Acesso aos hosts para seu computador. Para uma instância do Amazon EC2, você usará uma conexão SSH para acessar o host. Você precisará acessar o host para adicionar a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host. + Um cluster do Amazon Redshift em execução. Para obter informações sobre como iniciar um cluster, consulte o [Guia de conceitos básicos do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/). ## Processo de carregamento de dados Esta seção orienta você pelo processo de carregamento de dados de hosts remotos. As seções a seguir fornecem os detalhes de que você precisa para realizar cada etapa. + **[Etapa 1: Recuperar a chave pública do cluster e os endereços IP dos nós do cluster](#load-from-host-steps-retrieve-key-and-ips)** A chave pública permite que os nós de cluster do Amazon Redshift estabeleçam conexões SSH com os hosts remotos. Você usará o endereço IP de cada nó do cluster para configurar os grupos de segurança do host ou firewall para permitir o acesso de seu cluster Amazon Redshift usando esses endereços IP. + **[Etapa 2: Adicionar a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host](#load-from-host-steps-add-key-to-host)** Você adiciona a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host para que o host reconheça o cluster do Amazon Redshift e aceite a conexão SSH. + **[Etapa 3: Configurar o host para aceitar todos os endereços IP do cluster do Amazon Redshift](#load-from-host-steps-configure-security-groups)** Para Amazon EC2, modifique os grupos de segurança da instância para adicionar regras de entrada para aceitar os endereços IP do Amazon Redshift. Para outros hosts, modifique o firewall para que os nós do Amazon Redshift possam estabelecer conexões SSH com o host remoto. + **[Etapa 4: Obter a chave pública para o host](#load-from-host-steps-get-the-host-key)** Você pode, opcionalmente, especificar que o Amazon Redshift deve usar a chave pública para identificar o host. Você precisará localizar a chave pública e copiar o texto em seu arquivo de manifesto. + **[Etapa 5: Criar um arquivo manifesto](#load-from-host-steps-create-manifest)** O manifesto é um arquivo de texto formatado em JSON com os detalhes de que o Amazon Redshift precisa para se conectar aos hosts e buscar os dados. + **[Etapa 6: Carregar o arquivo manifesto para um bucket do Amazon S3](#load-from-host-steps-upload-manifest)** O Amazon Redshift lê o manifesto e usa essas informações para se conectar ao host remoto. Se o bucket do Amazon S3 não residir na mesma região que seu cluster Amazon Redshift, você deve usar a opção [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar a região na qual os dados estão localizados. + **[Etapa 7: Executar o comando COPY para carregar os dados](#load-from-host-steps-run-copy)** De um banco de dados do Amazon Redshift, execute o comando COPY para carregar os dados em uma tabela do Amazon Redshift. ## Etapa 1: Recuperar a chave pública do cluster e os endereços IP dos nós do cluster Você usará o endereço IP de cada nó do cluster para configurar os grupos de segurança do host para permitir o acesso de seu cluster Amazon Redshift usando esses endereços IP. **Para recuperar a chave pública do cluster e os endereços IP dos nós de seu cluster usando o console** 1. Acesse o Console de Gerenciamento do Amazon Redshift. 1. No painel de navegação, selecione o link **Clusters**. 1. Selecione seu cluster na lista. 1. Localize o grupo **Configurações de ingestão do SSH**. Observe a **Chave pública do cluster** e **Endereços IP dos nós**. Você vai usá-los em etapas subsequentes. ![\[Captura de tela do grupo Configurações de ingestão SSH mostrando a chave pública do cluster e os endereços IP do nó.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/copy-from-ssh-console-2.png) Você usará os endereços IP na Etapa 3 para configurar o host para aceitar a conexão do Amazon Redshift. Dependendo à qual tipo de host você se conectar e se ele está em uma VPC, você usará endereços IP públicos ou endereços IP privados. Para recuperar a chave pública do cluster e os endereços IP do nó do cluster para seu cluster usando a CLI do Amazon Redshift, execute o comando describe-clusters. Por exemplo: ``` aws redshift describe-clusters --cluster-identifier ``` A resposta incluirá o valor de ClusterPublicKey e a lista de endereços IP privados e públicos, semelhante ao seguinte: ``` { "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", ... ... } ``` Para recuperar a chave pública do cluster e os endereços IP do nó do cluster para o seu cluster usando a API Amazon Redshift, use a ação DescribeClusters. Para obter mais informações, consulte [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) no *Guia de CLI do Amazon Redshift* ou [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) no Guia de API do Amazon Redshift. ## Etapa 2: Adicionar a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host Você adiciona a chave pública do cluster ao arquivo de chaves autorizadas de cada host para que o host reconheça o Amazon Redshift e aceite a conexão SSH. **Para adicionar a chave pública do cluster do Amazon Redshift ao arquivo de chaves autorizadas do host** 1. Acesse o host usando uma conexão SSH. Para obter informações sobre como se conectar a uma instância usando SSH, consulte [Conectar-se à instância do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) no *Manual do usuário do Amazon EC2*. 1. Copie a chave pública do Amazon Redshift do console ou do texto de resposta da CLI. 1. Copie e cole os conteúdos da chave pública no arquivo `/home//.ssh/authorized_keys` no host remoto. O `` deve corresponder ao valor do campo "nome de usuário" no arquivo manifesto. Inclua a string completa com o prefixo “`ssh-rsa`” e o sufixo “`Amazon-Redshift`”. Por exemplo: ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Etapa 3: Configurar o host para aceitar todos os endereços IP do cluster do Amazon Redshift Se você estiver trabalhando com uma instância do Amazon EC2 ou um cluster do Amazon EMR, adicione regras de entrada ao grupo de segurança do host para permitir o tráfego de cada nó do cluster do Amazon Redshift. Para **Tipo**, selecione SSH com protocolo TCP na porta 22. Para **Fonte**, insira os endereços IP do nó do cluster do Amazon Redshift que você recuperou em [Etapa 1: Recuperar a chave pública do cluster e os endereços IP dos nós do cluster](#load-from-host-steps-retrieve-key-and-ips). Para obter informações sobre como adicionar regras a um grupo de segurança do Amazon EC2, consulte [Autorizar tráfego de entrada para as instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) no *Manual do usuário do Amazon EC2*. Use os endereços IP privados quando: + Você tem um cluster do Amazon Redshift que não está em uma Virtual Private Cloud (VPC) e uma instância do Amazon EC2-Classic, ambos na mesma região da AWS. + Você tem um cluster do Amazon Redshift que está em um VPC e uma instância do Amazon EC2 -VPC, ambos na mesma região da AWS e no mesmo VPC. Caso contrário, use os endereços IP públicos. Para obter mais informações sobre como usar o Amazon Redshift em uma VPC, consulte “[Gerenciamento de clusters em uma VPC](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*. ## Etapa 4: Obter a chave pública para o host Opcionalmente, você pode fornecer a chave pública do host no arquivo de manifesto para que o Amazon Redshift possa identificar o host. O comando COPY não requer a chave pública do host, mas por motivo de segurança, recomendamos veementemente o uso de uma chave pública para ajudar a evitar ataques “man-in-the-middle”. Você pode encontrar a chave pública do host no seguinte local, onde `` é o nome exclusivo para a chave pública do host: ``` : /etc/ssh/.pub ``` **nota** O Amazon Redshift é compatível somente com chaves RSA. Não oferecemos suporte para chaves DSA. Ao criar seu arquivo manifesto na etapa 5, você colará o texto da chave pública no campo “chave pública” na entrada do arquivo manifesto. ## Etapa 5: Criar um arquivo manifesto O comando COPY pode conectar-se a vários hosts usando SSH e criar várias conexões SSH para cada host. O COPY executa um comando em cada conexão do host e carrega a saída dos comandos para a tabela em paralelo. O arquivo manifesto é um arquivo de texto no formato JSON que o Amazon Redshift usa para se conectar ao host. O arquivo manifesto especifica os endpoints do host SSH e os comandos que serão executados nos hosts para retornar dados ao Amazon Redshift. Você também pode incluir a chave pública do host, o nome de usuário de login e um sinalizador obrigatório para cada entrada. Crie o arquivo manifesto no computador local. Em uma etapa posterior, você carrega o arquivo no Amazon S3. O arquivo manifesto está no seguinte formato: ``` { "entries": [ {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": ""}, {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": "host_user_name"} ] } ``` O arquivo manifesto contém um construto "entradas" para cada conexão SSH. Cada entrada representa uma única conexão SSH. Você pode ter várias conexões para um único host ou várias conexões para vários hosts. As aspas duplas são obrigatórias conforme mostrado, tanto para os nomes dos campos quanto para os valores. O único valor que não precisa de aspas duplas é o valor booleano **true** ou **false** para o campo obrigatório. Veja a seguir as descrições dos campos no arquivo manifesto. endpoint O endereço URL ou endereço IP do host. Por exemplo, "`ec2-111-222-333.compute-1.amazonaws.com`" ou "`22.33.44.56`" command O comando que será executado pelo host para gerar a saída de texto ou a saída binária (gzip, lzop ou bzip2). O comando pode ser qualquer um que o usuário *"host\$1user\$1name"* tenha permissão para executar. O comando pode ser tão simples quanto imprimir um arquivo ou pode ser consultar um banco de dados ou iniciar um script. A saída (arquivo de texto, arquivo binário gzip, arquivo binário lzop ou arquivo bzip2) deve estar em um formato que o comando COPY do Amazon Redshift possa ingerir. Para obter mais informações, consulte [Preparação de dados de entrada](t_preparing-input-data.md). publickey (Opcional) A chave pública do host. Se fornecida, o Amazon Redshift usará a chave pública para identificar o host. Se a chave pública não for fornecida, o Amazon Redshift não tentará a identificação do host. Por exemplo, se a chave pública do host remoto for: `ssh-rsa AbcCbaxxx…xxxDHKJ root@amazon.com`, insira o seguinte texto no campo de chave pública: `AbcCbaxxx…xxxDHKJ`. mandatory (Opcional) Indica se o comando COPY deve falhar se a conexão falhar. O padrão é `false`. Se o Amazon Redshift não fizer com sucesso pelo menos uma conexão, o comando COPY falhará. username (Opcional) O nome de usuário que será utilizado para fazer logon no sistema do host e executar o comando remoto. O nome de login do usuário deve ser o mesmo do login que foi usado para adicionar a chave pública ao arquivo de chaves autorizadas do host na etapa 2. O nome de usuário padrão é "redshift". O exemplo a seguir mostra um manifesto concluído para abrir quatro conexões ao mesmo host e executar um comando diferente em cada conexão: ``` { "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"} ] } ``` ## Etapa 6: Carregar o arquivo manifesto para um bucket do Amazon S3 Carregue o arquivo manifesto para um bucket do Amazon S3. Se o bucket do Amazon S3 não residir na mesma região da AWS que seu cluster do Amazon Redshift, você deve usar a opção [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar a região da AWS na qual o manifesto está localizado. Para obter informações sobre como criar um bucket do Amazon S3 e carregar um arquivo, consulte [Guia do usuário do Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/). ## Etapa 7: Executar o comando COPY para carregar os dados Execute um comando [COPY](r_COPY.md) para conectar-se ao host e carregar os dados em uma tabela do Amazon Redshift. No comando COPY, especifique o caminho do objeto Amazon S3 explícito para o arquivo manifesto e inclua a opção SSH. Por exemplo, ``` COPY sales FROM 's3://amzn-s3-demo-bucket/ssh_manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' SSH; ``` **nota** Se você usar a compactação automática, o comando COPY realizará duas leituras de dados, ou seja, executará o comando remoto duas vezes. A primeira leitura é para fornecer um exemplo para a análise de compactação e a segunda leitura efetivamente carrega os dados. Se a execução do comando remoto duas vezes causar um problema devido a possíveis efeitos colaterais, você deverá desativar a compactação automática. Para desativar a compactação automática, execute o comando COPY com a opção COMPUPDATE definida como desativado. Para obter mais informações, consulte [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md). # Carregar dados de uma tabela do Amazon DynamoDB Você pode usar o comando COPY para carregar uma tabela com dados de uma única tabela do Amazon DynamoDB. **Importante** A tabela do Amazon DynamoDB que fornece os dados deve ser criada na mesma região da AWS de seu cluster, a menos que você use a opção [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar a região da AWS na qual a tabela do Amazon DynamoDB está localizada. O comando COPY utiliza a arquitetura de processamento maciçamente paralelo (MPP) do Amazon Redshift para ler e carregar dados em paralelo de uma tabela do Amazon DynamoDB. Você pode tirar o máximo proveito do processamento paralelo definindo estilos de distribuição em suas tabelas do Amazon Redshift. Para obter mais informações, consulte [Distribuição de dados para otimização de consultas](t_Distributing_data.md). **Importante** Quando o comando COPY lê dados da tabela Amazon DynamoDB, o throughput resultante faz parte do throughput provisionado dessa tabela. Para evitar o consumo de quantidades excessivas de throughput de leitura provisionada, recomendamos que você não carregue dados de tabelas do Amazon DynamoDB que estão em ambientes de produção. Se você carregar dados de tabelas de produção, recomendamos que você defina a opção READRATIO muito mais baixa que a porcentagem média do throughput provisionado não utilizado. Uma baixa configuração de READRATIO ajudará a minimizar problemas de limitação. Para usar todo o throughput provisionado de uma tabela do Amazon DynamoDB, defina READRATIO como 100. O comando COPY combina os nomes dos atributos nos itens recuperados da tabela DynamoDB com os nomes das colunas em uma tabela existente do Amazon Redshift usando as seguintes regras: + As colunas da tabela do Amazon Redshift não fazem distinção entre maiúsculas e minúsculas com os atributos de item do Amazon DynamoDB. Se um item em uma tabela do DynamoDB contém vários atributos que diferem somente na capitalização, tal como Price e PRICE, o comando COPY falhará. + As colunas da tabela Amazon Redshift que não correspondem a um atributo na tabela Amazon DynamoDB são carregadas como NULL ou vazias, dependendo do valor especificado com a opção EMPTYASNULL no comando [COPY](r_COPY.md). + Os atributos do Amazon DynamoDB que não correspondem a uma coluna na tabela do Amazon Redshift são descartados. Os atributos são lidos antes de serem combinados, portanto mesmo os atributos descartados consomem parte do throughput provisionado da tabela. + Apenas atributos do Amazon DynamoDB com tipos de dados escalares STRING e NUMBER são aceitos. Os tipos de dados Amazon DynamoDB BINARY e SET não são aceitos. Se um comando COPY tentar carregar um atributo com um tipo de dados não compatível, o comando falhará. Se o atributo não corresponder a uma coluna da tabela Amazon Redshift, COPY não tentará carregá-lo e não gerará um erro. O comando COPY usa a seguinte sintaxe para carregar dados de uma tabela do Amazon DynamoDB: ``` COPY FROM 'dynamodb://' authorization readratio ''; ``` Os valores para *autorização* são as credenciais da AWS necessárias para acessar a tabela do Amazon DynamoDB. Se essas credenciais corresponderem a um usuário, ele deverá ter permissão para executar os comandos SCAN e DESCRIBE na tabela do Amazon DynamoDB que está sendo carregada. Os valores para *autorização* fornecem a autorização da AWS que seu cluster necessita para acessar a tabela do Amazon DynamoDB. A permissão deve incluir SCAN e DESCRIBE para a tabela do Amazon DynamoDB que está sendo carregada. Para obter mais informações sobre as permissões necessárias, consulte [Permissões do IAM para COPY, UNLOAD e CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). O método preferido de autenticação é especificar o parâmetro IAM\$1ROLE e fornecer o nome de recurso da Amazon (ARN) para uma função do IAM com as permissões necessárias. Para obter mais informações, consulte [Controle de acesso com base em função](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based). Para autenticação usando o parâmetro IAM\$1ROLE, ** e ** conforme exibido na sintaxe a seguir. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` O seguinte exemplo mostra a autenticação usando uma função do IAM. ``` COPY favoritemovies FROM 'dynamodb://ProductCatalog' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Para obter mais informações sobre outras opções de autorização, consulte [Parâmetros de autorização](copy-parameters-authorization.md) Se você quiser validar seus dados sem realmente carregar a tabela, use a opção NOLOAD com o comando [COPY](r_COPY.md). O exemplo a seguir carrega a tabela FAVORITEMOVIES com dados da tabela my-favorite-movies-table do DynamoDB. A atividade de leitura pode consumir até 50% do throughput provisionado. ``` COPY favoritemovies FROM 'dynamodb://my-favorite-movies-table' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' READRATIO 50; ``` Para maximizar o throughput, o comando COPY carrega dados de uma tabela do Amazon DynamoDB em paralelo entre os nós de computação no cluster. ## Throughput provisionado com compactação automática Por padrão, o comando COPY aplica a compactação automática sempre que você especifica uma tabela de destino vazia sem codificação de compactação. A análise de compressão automática inicialmente obtém amostras de um grande número de linhas da tabela Amazon DynamoDB. O tamanho da amostra é baseado no valor do parâmetro COMPROWS. O padrão é 100.000 linhas por fatia. Após o teste, as linhas da amostra são descartadas e a tabela inteira é carregada. Como resultado, muitas linhas são lidas duas vezes. Para obter mais informações sobre como funciona a compactação automática, consulte [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md). **Importante** Quando o comando COPY lê dados da tabela Amazon DynamoDB, incluindo as linhas usadas para amostragem, o throughput de dados resultante faz parte do throughput provisionado dessa tabela. ## Carregar dados multibyte do Amazon DynamoDB Se seus dados incluem caracteres multibyte não ASCII (tal como caracteres chineses ou cirílicos), você deve carregar os dados em colunas VARCHAR. O tipo de dados VARCHAR é compatível com caracteres UTF-8 de quatro bytes, mas o tipo de dados CHAR aceita apenas caracteres ASCII de único byte. Você não pode carregar caracteres de cinco bytes ou mais nas tabelas do Amazon Redshift. Para obter mais informações sobre CHAR e VARCHAR, consulte [Tipos de dados](c_Supported_data_types.md). # Como verificar se os dados foram carregados corretamente Após a conclusão da operação de carregamento, consulte a tabela de sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) para certificar-se de que os arquivos esperados foram carregados. Execute o comando COPY e a verificação do carregamento na mesma transação, para que seja possível reverter toda a transação se houver um problema com o carregamento. A consulta a seguir retorna as entradas para um carregamento de tabelas no banco de dados 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) ``` # Validação de dados de entrada Para validar os dados nos arquivos de entrada do Amazon S3 ou na tabela do Amazon DynamoDB antes de realmente carregar os dados, use a opção NOLOAD com o comando [COPY](r_COPY.md). Use NOLOAD com os mesmos comandos e opções de COPY que você usaria para carregar os dados. NOLOAD verifica a integridade de todos os dados sem carregá-los no banco de dados. A opção NOLOAD exibirá os erros que ocorrerão se você tentar carregar os dados. Por exemplo, se você especificou o caminho incorreto do Amazon S3 para o arquivo de entrada, o Amazon Redshift exibirá o erro a seguir. ``` 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] ----------------------------------------------- ``` Para solucionar mensagens de erro, consulte [Referência de erros de carregamento](r_Load_Error_Reference.md). Para ver um exemplo usando a opção NOLOAD, consulte [Comando COPY com a opção NOLOAD](r_COPY_command_examples.md#r_COPY_command_examples-load-noload-option). # Carregamento de tabelas com compactação automática Você pode aplicar codificações de compactação a colunas em tabelas manualmente com base em sua própria avaliação dos dados. Ou você pode usar o comando COPY com COMPUPDATE definido como ON para analisar e aplicar compactação automaticamente com base nos dados de amostra. Você pode usar a compactação automática ao criar e carregar uma nova tabela. O comando COPY executa uma análise de compactação. Você também pode executar uma análise de compactação sem carregar dados ou alterar a compactação em uma tabela executando o comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) em uma tabela já preenchida. Por exemplo, você pode executar ANALYZE COMPRESSION quando quiser analisar a compactação em uma tabela para uso futuro, preservando as instruções de linguagem de definição de dados (DDL) existentes. A compactação automática equilibra a performance geral ao escolher codificações de compactação. As varreduras restritas por intervalo podem apresentar má performance se as colunas de chaves de classificação forem mais altamente compactadas do que outras colunas na mesma consulta. Como resultado, a compactação automática ignora a fase de análise de dados nas colunas de chave de classificação e mantém os tipos de codificação definidos pelo usuário. A compactação automática escolherá a codificação RAW se você não tiver definido explicitamente um tipo de codificação. ANALYZE COMPRESSION se comporta da mesma forma. Para obter a performance ideal de consultas, considere o uso de RAW para chaves de classificação. ## Como a compactação automática funciona Quando o parâmetro COMPUPDATE é definido como ON, o comando COPY aplica a compactação automática sempre que você executa o comando COPY com uma tabela de destino vazia e todas as colunas da tabela têm a codificação RAW ou nenhuma codificação. Para aplicar a compactação automática em uma tabela vazia, independentemente de suas codificações atuais de compactação, execute o comando COPY com a opção COMPUPDATE definida como ON. Para desativar a compactação automática, execute o comando COPY com a opção COMPUPDATE definida como desativado. Você não pode aplicar a compactação automática em uma tabela que já contém dados. **nota** A análise de compactação automática requer linhas suficientes nos dados de carregamento (pelo menos 100.000 linhas por fatia) para gerar uma amostra significativa. A compactação automática executa essas operações em segundo plano como parte da transação de carregamento: 1. Uma amostra inicial das linhas do arquivo de entrada é carregada. O tamanho da amostra é baseado no valor do parâmetro COMPROWS. O padrão é 100,000. 1. As opções de compactação são escolhidas para cada coluna. 1. As linhas da amostra são removidas da tabela. 1. A tabela é recriada com as codificações de compactação escolhidas. 1. O arquivo de entrada é carregado e compactado usando as novas codificações. Quando você executa o comando COPY, a tabela é totalmente carregada, compactada e está pronta para uso. Se você carregar mais dados depois, as linhas adicionadas são compactadas de acordo com a codificação existente. Se você deseja executar somente uma análise de compactação, execute ANALYZE COMPRESSION que é mais eficiente que a execução de um COPY completo. Então, você pode avaliar os resultados para decidir se deve usar a compactação automática ou recriar a tabela manualmente. A compactação automática é compatível somente com o comando COPY. Como alternativa, você pode aplicar a codificação de compactação manualmente ao criar a tabela. Para obter informações sobre a codificação de compactação manual, consulte [Compactação de colunas para reduzir o tamanho dos dados armazenados](t_Compressing_data_on_disk.md). ## Exemplo de compactação automática Neste exemplo, suponha que o banco de dados TICKIT contenha uma cópia da tabela LISTING chamada BIGLIST e que você queira aplicar a compactação automática nessa tabela quando ela estiver carregada com aproximadamente 3 milhões de linhas. **Para carregar e compactar automaticamente a tabela** 1. A tabela deve estar vazia. Você pode aplicar a compactação automática somente em uma tabela vazia: ``` TRUNCATE biglist; ``` 1. Carregue a tabela com um único comando COPY. Embora a tabela esteja vazia, alguma codificação anterior pode ter sido especificada. Para garantir que o Amazon Redshift execute uma análise de compactação, defina o parâmetro COMPUPDATE como ativado. ``` COPY biglist FROM 's3://amzn-s3-demo-bucket/biglist.txt' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' COMPUPDATE ON; ``` Como nenhuma opção COMPROWS está especificada, o tamanho padrão e recomendado de amostra de 100.000 linhas por fatia é usado. 1. Observe o novo esquema para a tabela BIGLIST para revisar os esquemas de codificação escolhidos 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. Verifique que o número esperado de linhas foi carregado: ``` select count(*) from biglist; count --------- 3079952 (1 row) ``` Quando linhas forem adicionadas posteriormente a essa tabela usando instruções COPY ou INSERT, as mesmas codificações de compactação serão aplicadas. # Otimização de armazenamento para tabelas estreitas Se você tiver uma tabela com muito poucas colunas, mas um número muito grande de linhas, as três colunas de identidade de metadados ocultas (INSERT\$1XID, DELETE\$1XID, ROW\$1ID) consumirão uma quantidade desproporcional de espaço em disco para a tabela. Para otimizar a compactação das colunas ocultas, carregue a tabela em uma única transação COPY sempre que possível. Se você carregar a tabela com vários comandos COPY distintos, a coluna INSERT\$1XID não será bem compactada. Você deverá realizar uma operação de limpeza se usar vários comandos COPY, mas isso não melhorará a compactação de INSERT\$1XID. # Carregamento de valores padrão de coluna Opcionalmente, é possível definir uma lista de colunas em seu comando COPY. Se uma coluna na tabela for omitida da lista de colunas, COPY carregará a coluna com o valor fornecido pela opção DEFAULT especificada no comando CREATE TABLE ou com NULL, se a opção DEFAULT não tiver sido especificada. Se COPY tentar atribuir NULL a uma coluna definida como NOT NULL, o comando COPY falhará. Para informações sobre como atribuir a opção DEFAULT, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md). Ao carregar de arquivos de dados no Amazon S3, as colunas na lista de colunas devem estar na mesma ordem que os campos no arquivo de dados. Se um campo no arquivo de dados não tem uma coluna correspondente na lista de coluna, o comando COPY falha. Ao carregar da tabela do Amazon DynamoDB, a ordem não importa. Todos os campos nos atributos do Amazon DynamoDB que não correspondem a uma coluna na tabela do Amazon Redshift são descartados. As seguintes restrições se aplicam ao usar o comando COPY para carregar valores DEFAULT em uma tabela: + Se uma coluna [IDENTITY](r_CREATE_TABLE_NEW.md#identity-clause) é incluída na lista de colunas, a opção EXPLICIT\$1IDS também deve ser especificada no comando [COPY](r_COPY.md) ou o comando COPY falha. Da mesma forma, se uma coluna IDENTITY é omitida da lista de colunas e a opção EXPLICIT\$1IDS é especificada, a operação COPY falha. + Como a expressão DEFAULT avaliada para determinada coluna é a mesma para todas as linhas carregadas, uma expressão DEFAULT que usa uma função RANDOM() atribuirá o mesmo valor para todas as linhas. + As expressões PADRÃO contendo CURRENT\$1DATE ou SYSDATE são definidas com o timestamp da transação atual. Para obter um exemplo, consulte “Carregar dados de um arquivo com valores padrão” em [Exemplos de COPY](r_COPY_command_examples.md). # Solução de problemas de carregamento de dados Ao carregar dados em tabelas do Amazon Redshift, você pode se deparar com erros do Amazon S3, dados de entrada inválidos e erros do comando COPY. As seções a seguir fornecem informações sobre como identificar e solucionar erros de carregamentos de dados. **Topics** + [Solução de problemas de integração de eventos do S3 e erros de COPY JOB](s3-integration-troubleshooting.md) + [Erros S3ServiceException](s3serviceexception-error.md) + [Tabelas de sistema para solucionar problemas de carregamento de dados](system-tables-for-troubleshooting-data-loads.md) + [Erros no carregamento de caracteres multibyte](multi-byte-character-load-errors.md) + [Referência de erros de carregamento](r_Load_Error_Reference.md) # Solução de problemas de integração de eventos do S3 e erros de COPY JOB Use as informações a seguir para solucionar problemas comuns com integrações de eventos do Amazon S3 e COPY JOB com o Amazon Redshift. ## Falha na criação da integração de eventos do S3 Se a criação da integração de eventos do S3 falhar, o status da integração será `Inactive`. Verifique se os seguintes itens estão corretos para o data warehouse do Amazon Redshift: + Você adicionou a entidade principal autorizada e a origem de integração correta ao namespace de destino no Amazon Redshift. Consulte [Pré-requisitos para criar uma integração de eventos do S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). + Você adicionou a política baseada em recursos correta ao bucket de origem do Amazon S3. Consulte [Pré-requisitos para criar uma integração de eventos do S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). ## Os dados do Amazon S3 não estão aparecendo no banco de dados de destino Se os dados de um COPY JOB não aparecerem, verifique o seguinte: + Consulte SYS\$1COPY\$1JOB\$1DETAIL para ver se o arquivo do Amazon S3 foi carregado, se a ingestão está pendente ou se há um erro. Para obter mais informações, consulte [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md). + Consulte STL\$1ERROR ou SYS\$1COPY\$1JOB\$1INFO se o arquivo do Amazon S3 não estiver lá ou se houver um tempo de espera inesperado. Procure por erros de credenciais ou um detalhe que sugira que a integração está inativa. Para obter mais informações, consulte [STL\$1ERROR](r_STL_ERROR.md) e [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md). # Erros S3ServiceException Os erros mais comuns de s3ServiceException são causados por uma string de credenciais incorreta ou formatada incorretamente, tendo seu cluster e seu bucket em diferentes regiões da AWS e permissões insuficientes do Amazon S3. A seção fornece informações para a solução de problemas de cada tipo de erro. ## String de credenciais inválida Se sua string de credenciais foi formatada inadequadamente, você receberá a seguinte mensagem de erro: ``` ERROR: Invalid credentials. Must be of the format: credentials 'aws_access_key_id=;aws_secret_access_key= [;token=]' ``` Verifique se a sequência de credenciais não contém espaços ou quebras de linha e está entre aspas simples. ## ID de chave de acesso inválido Se seu ID de chave de acesso não existir, você receberá a seguinte mensagem de erro: ``` [Amazon](500310) Invalid operation: S3ServiceException:The AWS Access Key Id you provided does not exist in our records. ``` Muitas vezes, trata-se de um erro de copiar e colar. Certifique-se de que o ID de chave de acesso foi inserido corretamente. Além disso, se você está usando chaves de sessão temporárias, verifique se o valor de `token` foi definido. ## Chave de acesso secreta inválida Se sua chave de acesso secreta estiver incorreta, você receberá a seguinte mensagem de erro: ``` [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 ``` Muitas vezes, trata-se de um erro de copiar e colar. Certifique-se de que a chave de acesso secreta foi inserida corretamente e que ela é a chave correta para o ID de chave de acesso. ## O bucket está em uma região diferente O bucket do Amazon S3 especificado no comando COPY deve estar na mesma região do cluster AWS. Se o seu bucket do Amazon S3 e seu cluster estiverem em regiões diferentes, você receberá um erro semelhante ao seguinte: ``` ERROR: S3ServiceException:The bucket you are attempting to access must be addressed using the specified endpoint. ``` Você pode criar um bucket do Amazon S3 em uma região específica selecionando a região ao criar o bucket usando o Console de Gerenciamento do Amazon S3 ou especificando um endpoint ao criar o bucket usando a API ou CLI do Amazon S3. Para obter mais informações, consulte [Carregar arquivos no Amazon S3 para usar com COPY](t_uploading-data-to-S3.md). Para mais informações sobre regiões do Amazon S3, consulte [Acessar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html#access-bucket-intro) no *Guia do usuário do Amazon Simple Storage Service*. Você também pode especificar a região usando a opção [REGION](copy-parameters-data-source-s3.md#copy-region) com o comando COPY. ## Acesso negado Se o usuário não tiver permissões suficientes, você receberá a seguinte mensagem de erro: ``` ERROR: S3ServiceException:Access Denied,Status 403,Error AccessDenied ``` Uma possível causa é o usuário identificado pelas credenciais não ter acesso de LIST e GET ao bucket do Amazon S3. Para outras causas, consulte [Solucionar erros de Acesso Negado (403 Proibido) no Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html) no *Guia do usuário do Amazon Simple Storage Service*. Para obter informações sobre o gerenciamento do acesso de usuários aos buckets, consulte [Gerenciamento de identidade e acesso no Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) no *Guia do usuário do Amazon Simple Storage Service*. # Tabelas de sistema para solucionar problemas de carregamento de dados As seguintes tabelas de sistema do Amazon Redshift podem ser úteis na solução de problemas de carregamento de dados: + Consulte [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) para descobrir erros que ocorreram durante os carregamentos específicos. + Consulte [STL\$1FILE\$1SCAN](r_STL_FILE_SCAN.md) para visualizar o tempo de carregamento de arquivos específicos ou para ver se um arquivo específico foi mesmo lido. + Consulte [STL\$1S3CLIENT\$1ERROR](r_STL_S3CLIENT_ERROR.md) para encontrar detalhes de erros encontrados durante a transferência de dados do Amazon S3. **Para encontrar e diagnosticar erros de carregamento** 1. Crie uma exibição ou defina uma consulta que retorne detalhes dos erros de carregamento. O seguinte exemplo junta a tabela STL\$1LOAD\$1ERRORS à tabela STV\$1TBL\$1PERM a IDs para comparar os IDs de tabela aos nomes reais da tabela. ``` 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. Defina a opção MAXERRORS em seu comando COPY como um valor grande o suficiente para permitir que COPY retorne informações úteis sobre seus dados. Se COPY encontrar erros, uma mensagem de erro o direciona a consultar a tabela STL\$1LOAD\$1ERRORS para obter detalhes. 1. Consulte a exibição LOADVIEW para visualizar detalhes de erros. Por exemplo: ``` 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. Corrija o problema no arquivo de entrada ou no script do carregamento com base nas informações que a exibição retorna. Alguns erros típicos de carregamento a observar incluem: + Divergência entre os tipos de dados na tabela e valores nos campos nos dados de entrada. + Divergência entre o número de colunas na tabela e o número de campos nos dados de entrada. + Aspas incompatíveis. O Amazon Redshift oferece suporte a aspas simples e duplas; no entanto, essas aspas devem ser balanceadas adequadamente. + Formato incorreto de dados de data/hora nos arquivos de entrada. + Valores fora do intervalo nos arquivos de entrada (para colunas numéricas). + O número de valores distintos de uma coluna excede a limitação de sua codificação de compactação. # Erros no carregamento de caracteres multibyte As colunas com um tipo de dados CHAR aceitam somente caracteres UTF-8 de único byte, com valor de byte de até 127, ou 7F hex, que também é o conjunto de caracteres ASCII. Colunas VARCHAR aceitam caracteres UTF-8 multibyte até o máximo de quatro bytes. Para obter mais informações, consulte [Tipos de caracteres](r_Character_types.md). Se uma linha em seus dados de carregamento contiver um caractere que não for válido para o tipo de dados da coluna, COPY retornará um erro e registrará uma linha na tabela de log de sistema STL\$1LOAD\$1ERRORS com o erro número 1220. O campo ERR\$1REASON inclui a sequência de bytes, em hex, para o caractere inválido. Uma alternativa para corrigir caracteres não válidos em seus dados de carregamento é substituir os caracteres não válidos durante o processo de carregamento. Para substituir os caracteres UTF-8 não válidos, especifique a opção ACCEPTINVCHARS com o comando COPY. Se a opção ACCEPTINVCHARS estiver definida, o caractere especificado substituirá o ponto de código. Se a opção ACCEPTINVCHARS não estiver definida, o Amazon Redshift aceitará os caracteres como UTF-8 válidos. Para obter mais informações, consulte [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars). A lista de pontos de código a seguir são caracteres UTF-8 válidos. As operações COPY não retornarão um erro se a opção ACCEPTINVCHARS não estiver definida. No entanto, esses pontos de código são caracteres inválidos. Use opção [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars) para substituir o ponto de código por um caractere especificado por você. Esses pontos de código incluem o intervalo de valores de `0xFDD0` a `0xFDEF` e valores até `0x10FFFF`, terminados em `FFFE` ou `FFFF`: + `0xFFFE`, `0x1FFFE`, `0x2FFFE`, …, `0xFFFFE`, `0x10FFFE` + `0xFFFF`, `0x1FFFF`, `0x2FFFF`, …, `0xFFFFF`, `0x10FFFF` O exemplo a seguir mostra o motivo do erro quando COPY tenta carregar o caractere UTF-8 `e0 a1 c7a4` em uma coluna CHAR: ``` Multibyte character not supported for CHAR (Hint: Try using VARCHAR). Invalid char: e0 a1 c7a4 ``` Se o erro for relacionado a um tipo de dados VARCHAR, o motivo do erro incluirá um código de erro e a sequência hexadecimal UTF-8 inválida. O exemplo a seguir mostra o motivo do erro quando COPY tenta carregar UTF-8 `a4` em um campo VARCHAR: ``` String contains invalid or unsupported UTF-8 codepoints. Bad UTF-8 hex sequence: a4 (error 3) ``` A tabela a seguir lista as descrições e ações alternativas sugeridas para erros de carregamento VARCHAR. Se um desses erros ocorrer, substitua o caractere com uma sequência de código UTF-8 válida ou remova o caractere. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/multi-byte-character-load-errors.html) # Referência de erros de carregamento Se um erro ocorrer durante o carregamento de dados de um arquivo, consulte a tabela [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) para identificar o erro e determinar a possível explicação. A tabela a seguir lista todos os códigos de erros que podem ocorrer durante carregamentos de dados: ## Códigos de erro de carregamento [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_Load_Error_Reference.html) # Criar uma integração de eventos do S3 para copiar automaticamente arquivos de buckets do Amazon S3 **nota** A versão de pré-visualização para cópia automática foi encerrada. Consequentemente, os clusters de visualização serão removidos automaticamente trinta dias após o término do período de visualização. Se você planeja continuar usando a cópia automática, recomendamos recriar seus trabalhos de cópia automática existentes em outro cluster do Amazon Redshift. Não é possível fazer a atualização de um cluster de visualização prévia para a versão mais recente do Amazon Redshift. Você pode usar uma tarefa de cópia automática para carregar dados em suas tabelas do Amazon Redshift usando arquivos armazenados no Amazon S3. O Amazon Redshift detecta quando novos arquivos do Amazon S3 são adicionados ao caminho especificado em seu comando COPY. Depois, um comando COPY é executado automaticamente sem que você precise criar um pipeline externo de ingestão de dados. O Amazon Redshift mantém o controle de quais arquivos foram carregados. O Amazon Redshift determina o número de arquivos agrupados por comando COPY. Você pode ver os comandos COPY resultantes nas visualizações do sistema. O primeiro passo para criar um COPY JOB automático é criar uma integração de eventos do S3. Quando um novo arquivo aparece no bucket de origem do Amazon S3, o Amazon Redshift gerencia o carregamento dos arquivos no banco de dados usando o comando COPY. ## Pré-requisitos para criar uma integração de eventos do S3 Para configurar a integração de eventos do S3, confirme se os pré-requisitos a seguir foram atendidos. + O bucket do Amazon S3 deve ter uma política de bucket que conceda diversas permissões do Amazon S3. Por exemplo, a política de exemplo a seguir concede permissões para o bucket de recursos `amzn-s3-demo-bucket` que está hospedado em *us-east-1*. Tanto o bucket do Amazon S3 quanto a integração estão na mesma Região da 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" } } } ] } ``` ------ + O cluster provisionado do Amazon Redshift de destino ou o namespace do Redshift sem servidor deve ter permissão para o bucket. Confirme se o perfil do IAM associado ao cluster ou namespace sem servidor tem uma política do IAM que concede as permissões adequadas. A política deve permitir `s3:GetObject` para um recurso de bucket, como `amzn-s3-demo-bucket`, e `s3:ListBucket` para um recurso de bucket e o respectivo conteúdo, como `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/*" ] } ] } ``` ------ Adicione a política a um perfil do IAM que tenha uma relação de confiança para o perfil da seguinte maneira: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Se o data warehouse de destino for um cluster provisionado, você poderá associar um perfil do IAM ao cluster provisionado usando o console do Amazon Redshift na guia **Permissões do cluster** nos detalhes do cluster. Para obter informações sobre como associar um perfil ao cluster provisionado, consulte [Associar funções do IAM a clusters](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role-associating-with-clusters.html) no *Guia de gerenciamento do Amazon Redshift*. Se o data warehouse de destino for o Redshift sem servidor, você poderá associar o perfil do IAM ao namespace sem servidor usando o console do Redshift sem servidor, na guia **Segurança e criptografia** nos detalhes do namespace. Para obter informações sobre como associar um perfil ao namespace sem servidor, consulte [Conceder as permissões necessárias para o Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-security-other-services.html) no *Guia de gerenciamento do Amazon Redshift*. + O data warehouse do Amazon Redshift também deve ter uma política de recursos que permita o bucket do Amazon S3. Se você usar o console do Amazon Redshift, ao criar a integração de eventos do S3, o Amazon Redshift fornecerá a opção **Corrigir para mim** para adicionar essa política ao data warehouse do Amazon Redshift. Para atualizar uma política de recursos, você pode usar o comando [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/redshift/put-resource-policy.html) da AWS CLI. Por exemplo, para anexar uma política de recursos ao cluster provisionado do Amazon Redshift e realizar uma integração de eventos do S3 com um bucket do Amazon S3, execute um comando da AWS CLI semelhante ao apresentado abaixo. O exemplo a seguir mostra uma política para um namespace de cluster provisionado na Região da AWS *us-east-1* referente à conta de usuário *123456789012*. O nome do bucket é *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" ``` Onde `rs-rp.json` contém: ------ #### [ 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 } } } ] } ``` ------ Para anexar uma política de recursos ao namespace do Redshift sem servidor e realizar uma integração de eventos do S3 com um bucket do Amazon S3, execute um comando da AWS CLI semelhante ao apresentado abaixo. O exemplo a seguir mostra uma política para um namespace sem servidor na Região da AWS *us-east-1* referente à conta de usuário *123456789012*. O nome do bucket é *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" ``` Onde `rs-rp.json` contém: ------ #### [ 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 } } } ] } ``` ------ ## Criar uma integração de eventos do S3 Para configurar o trabalho de cópia, primeiro defina uma integração de eventos do S3. ------ #### [ Amazon Redshift console ] **Como criar uma integração de eventos do Amazon S3 no console do Amazon Redshift** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. No painel de navegação à esquerda, selecione **Integração de eventos do S3**. 1. Escolha **Criar integração de eventos do Amazon S3** para abrir o assistente e criar uma integração de eventos do S3 para usar com cópia automática. O bucket de origem do Amazon S3 e o data warehouse de destino do Amazon Redshift devem estar na mesma Região da AWS. Especifique as seguintes informações ao executar as etapas para criar uma integração: + **Nome da integração**: é um identificador exclusivo entre todas as integrações de propriedade da Conta da AWS na Região da AWS atual. + **Descrição**: é um texto que descreve a integração de eventos do Amazon S3 para referência posterior. + **Bucket do S3 de origem**: o bucket do Amazon S3 está na Conta da AWS e Região da AWS atual, que é a origem dos dados de ingestão no Amazon Redshift. + **Data warehouse do Amazon Redshift**: é o cluster provisionado do Amazon Redshift de destino ou o grupo de trabalho do Redshift sem servidor que recebe os dados da integração. Se o Amazon Redshift de destino estiver na mesma conta, você poderá selecionar o destino. Se o destino estiver em uma conta diferente, especifique o **ARN do data warehouse do Amazon Redshift**. O destino deve ter uma política de recursos com entidades principais autorizadas e origem de integração. Se você não tiver as políticas de recursos corretas no destino e ele estiver na mesma conta, selecione a opção **Corrigir isso para mim** para aplicar automaticamente as políticas de recursos durante o processo de criação da integração. Se o destino estiver em uma Conta da AWS diferente, você precisará aplicar manualmente a política de recursos no warehouse do Amazon Redshift. 1. Insira até 50 **Chaves** de tag e com um **valor** opcional para fornecer metadados adicionais sobre a integração. 1. É exibida uma página de revisão na qual você pode selecionar **Criar integração de eventos do S3**. ------ #### [ AWS CLI ] Para criar uma integração de eventos do Amazon S3 usando a AWS CLI, use o comando `create-integration` com as seguintes opções: + `integration-name`: especifique um nome para a integração. + `source-arn`: especifique o ARN do bucket de origem do Amazon S3. + `target-arn`: especifique o ARN do namespace do cluster provisionado do Amazon Redshift ou do destino do grupo de trabalho do Redshift sem servidor. O exemplo a seguir cria uma integração fornecendo o nome da integração, o ARN de origem e o ARN de destino. A integração não é criptografada. ``` 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": [] } ``` Você também pode usar os comandos da AWS CLI a seguir para gerenciar sua integração de eventos do S3. + `delete-integration`: especifique um ARN de integração para excluir uma integração de eventos do S3. + `modify-integration`: especifique um ARN de integração para alterar o nome ou a descrição (ou ambos) de uma integração de eventos do S3. + `describe-integrations`: especifique um ARN de integração para visualizar as propriedades de uma integração de eventos do S3. Consulte o [https://docs.aws.amazon.com/cli/latest/reference/redshift/](https://docs.aws.amazon.com/cli/latest/reference/redshift/) para obter mais informações sobre esses comandos. ------ O Amazon Redshift então cria uma integração de eventos do S3 com a origem e o destino associados, o status e as informações sobre o status de um trabalho de cópia automática correspondente. Você pode visualizar informações sobre uma integração de eventos do S3 no console do Amazon Redshift escolhendo **Integrações de eventos do S3** e selecionando a integração para mostrar os detalhes. As integrações são separadas entre aquelas criadas **Na minha conta** e **De outras contas**. A lista **Na minha conta** mostra integrações em que a origem e o destino estão na mesma conta. A lista **De outras contas** mostra integrações em que a origem pertence a outra conta. Se você excluir uma integração de eventos do S3, o status correspondente do COPY JOB mudará de `1` (ativo) para `0` (inativo/pendente). Entretanto, o COPY JOB correspondente não é descartado automaticamente. Se mais tarde você tentar criar um COPY JOB com o mesmo nome, poderá haver um conflito. ## Criar e monitorar um COPY JOB Depois que a integração for criada, na página **Detalhes da integração de eventos do S3** da integração que você criou, selecione **Criar tarefa de cópia automática** para acessar o Editor de Consultas V2 do Amazon Redshift, no qual você pode criar a tarefa de cópia automática para a integração. O Amazon Redshift compara o bucket na cláusula FROM na instrução COPY JOB CREATE com o bucket usado na integração de eventos do S3. Para obter mais informações sobre o Editor de Consultas V2 do Amazon Redshift, acesse [Consultar um banco de dados usando o Editor de Consultas V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2.html) no *Guia de gerenciamento do Amazon Redshift*. Por exemplo, execute o comando COPY a seguir no Editor de Consultas V2 para criar um COPY JOB automático que associe o bucket `s3://amzn-s3-demo-bucket/staging-folder` do Amazon S3 a uma integração de eventos do 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; ``` Você define um COPY JOB uma vez. Os mesmos parâmetros serão usados em execuções futuras. Para definir e gerenciar um COPY JOB, você deve ter permissão. Para obter informações sobre como conceder e revogar permissão em um COPY JOB, consulte [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md). Para obter mais informações sobre como conceder e revogar permissões com escopo definido para um COPY JOB, consulte [Concessão de permissões em escopo](r_GRANT.md#grant-scoped-syntax) e [Revogação de permissões em escopo](r_REVOKE.md#revoke-scoped-permissions). Você gerencia as operações de carregamento usando as opções CREATE, LIST, SHOW, DROP, ALTER e RUN para trabalhos. Para obter mais informações, consulte [COPY JOB](r_COPY-JOB.md). Você pode consultar as visualizações do sistema para ver o status e o progresso de COPY JOB. As visualizações são fornecidas da seguinte forma: + [SYS\$1COPY\$1JOB](SYS_COPY_JOB.md): contém uma linha para cada COPY JOB definido no momento. + [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md): contém detalhes sobre arquivos pendentes, com erro e ingeridos para cada COPY JOB. + [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md): contém mensagens registradas sobre um COPY JOB. + [SYS\$1LOAD\$1HISTORY](SYS_LOAD_HISTORY.md): contém detalhes de comandos COPY. + [SYS\$1LOAD\$1ERROR\$1DETAIL](SYS_LOAD_ERROR_DETAIL.md): contém detalhes de erros de comandos COPY. + [SVV\$1COPY\$1JOB\$1INTEGRATIONS](SVV_COPY_JOB_INTEGRATIONS.md): contém detalhes das integrações de eventos do S3. + [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md): contém erros de comandos COPY. + [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md): contém informações usadas para solucionar problemas de carregamento de dados do comando COPY. Para obter informações sobre como solucionar erros de integração de eventos do S3, consulte [Solução de problemas de integração de eventos do S3 e erros de COPY JOB](s3-integration-troubleshooting.md). Para obter a lista de arquivos carregados por um COPY JOB, execute o seguinte SQL, mas primeiro substitua **: ``` 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 = ; ``` ## Considerações ao criar uma integração de eventos do S3 para cópia automática Considere o seguinte ao usar a cópia automática: + Você pode criar no máximo 200 COPY JOBS para cada cluster ou grupo de trabalho em uma Conta da AWS. + Você pode criar no máximo 50 integrações de eventos do S3 para cada destino do Amazon Redshift. + Não é possível criar uma integração de eventos do S3 com um bucket de origem do Amazon S3 que tenha um ponto (.) no nome do bucket. + Só é possível criar uma integração de eventos do S3 entre a mesma origem e destino. Ou seja, só pode haver uma integração de eventos do S3 entre um bucket do Amazon S3 e um data warehouse do Amazon Redshift por vez. + Você não pode ter nenhuma notificação de evento existente para o tipo de evento `S3_OBJECT_CREATED` que esteja definido no bucket de origem do Amazon S3. No entanto, após a criação de uma integração de eventos do S3, é possível atualizar a notificação de eventos do bucket do Amazon S3 usando um prefixo/sufixo com um escopo mais restrito. Dessa forma, você também pode configurar `S3_OBJECT_CREATED` para outro prefixo/sufixo de outros destinos e evitar um conflito com a integração de eventos do S3. Se você enfrentar problemas em que a cópia automática não estava sendo executada como esperado, prepare o log do AWS CloudTrail da ação `s3:PutBucketNotificationConfiguration` no bucket do S3 para o período em questão ao entrar em contato com o AWS Support. ## Regiões com suporte As regiões a seguir estão disponíveis para cópia automática. | Região | Cópia automática | | --- | --- | | África (Cidade do Cabo) | Available (Disponível) | | Ásia-Pacífico (Hong Kong) | Available (Disponível) | | Ásia-Pacífico (Taipei) | Available (Disponível) | | Ásia-Pacífico (Tóquio) | Available (Disponível) | | Ásia-Pacífico (Seul) | Available (Disponível) | | Ásia-Pacífico (Osaka) | Available (Disponível) | | Ásia-Pacífico (Mumbai) | Available (Disponível) | | Ásia-Pacífico (Hyderabad) | Available (Disponível) | | Ásia-Pacífico (Singapura) | Available (Disponível) | | Ásia-Pacífico (Sydney) | Available (Disponível) | | Ásia-Pacífico (Jacarta) | Available (Disponível) | | Ásia-Pacífico (Melbourne) | Available (Disponível) | | Ásia-Pacífico (Malásia) | Available (Disponível) | | Ásia-Pacífico (Nova Zelândia) | Indisponível | | Ásia-Pacífico (Tailândia) | Available (Disponível) | | Canadá (Central) | Available (Disponível) | | Oeste do Canadá (Calgary) | Available (Disponível) | | China (Pequim) | Available (Disponível) | | China (Ningxia) | Available (Disponível) | | Europa (Frankfurt) | Available (Disponível) | | Europa (Zurique) | Available (Disponível) | | Europa (Estocolmo) | Available (Disponível) | | Europa (Milão) | Available (Disponível) | | Europa (Espanha) | Available (Disponível) | | Europa (Irlanda) | Available (Disponível) | | Europa (Londres) | Available (Disponível) | | Europa (Paris) | Available (Disponível) | | Israel (Tel Aviv) | Available (Disponível) | | Oriente Médio (Emirados Árabes Unidos) | Available (Disponível) | | Oriente Médio (Bahrein) | Available (Disponível) | | México (Centro) | Available (Disponível) | | América do Sul (São Paulo) | Available (Disponível) | | Leste dos EUA (Norte da Virgínia) | Available (Disponível) | | Leste dos EUA (Ohio) | Available (Disponível) | | Oeste dos EUA (N. da Califórnia) | Available (Disponível) | | Oeste dos EUA (Oregon) | Available (Disponível) | | AWS GovCloud (Leste dos EUA) | Available (Disponível) | | AWS GovCloud (Oeste dos EUA) | Available (Disponível) | # Carregar tabelas com comandos DML O Amazon Redshift oferece suporte a comandos de linguagem de manipulação de dados (DML) padrão (INSERT, UPDATE e DELETE) que você pode usar para modificar linhas em tabelas. Você também pode usar o comando TRUNCATE para fazer exclusões em massa rápidas. **nota** Recomendamos veementemente o uso do comando [COPY](r_COPY.md) para carregar grandes quantidades de dados. O uso de instruções INSERT individuais para povoar uma tabela pode ser proibitivamente lento. Como alternativa, se seus dados já existem em outras tabelas de banco de dados do Amazon Redshift, use INSERT INTO... SELECT FROM ou CREATE TABLE AS para aprimorar a performance. Para obter informações, consulte [INSERT](r_INSERT_30.md) ou [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Se você inserir dados, atualizar ou excluir um número significativo de linhas de uma tabela em relação ao número de linhas antes das alterações, execute os comandos ANALYZE e VACUUM na tabela quando você tiver terminado. Se um número de pequenas alterações se acumula ao longo do tempo em seu aplicativo, você pode querer agendar a execução dos comandos ANALYZE e VACUUM em intervalos regulares. Para obter mais informações, consulte [Análise de tabelas](t_Analyzing_tables.md) e [Vacuum de tabelas](t_Reclaiming_storage_space202.md). **Topics** + [Atualização e inserção de novos dados](t_updating-inserting-using-staging-tables-.md) # Atualização e inserção de novos dados É possível adicionar novos dados de forma eficiente a uma tabela existente usando o comando MERGE. Execute uma operação de mesclagem criando uma tabela intermediária e, depois, use um dos métodos descritos nesta seção para atualizar a tabela de destino pela tabela de preparação. Para obter mais informações sobre o comando MERGE, consulte [MERGE](r_MERGE.md). O [Exemplos de mesclagem](merge-examples.md) usa um exemplo de conjunto de dados para o Amazon Redshift, chamado conjunto de dados TICKIT. Como pré-requisito, você pode configurar as tabelas e os dados do TICKIT seguindo as instruções disponíveis em [Conceitos básicos das tarefas comuns do banco de dados](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Informações mais detalhadas sobre o exemplo de conjunto de dados estão disponíveis em [Exemplo de banco de dados](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). ## Método de mesclagem 1: substituição de linhas existentes Se você estiver sobrescrevendo todas as colunas na tabela de destino, o método mais rápido para realizar uma mesclagem será substituir as linhas existentes. Isso verifica a tabela de destino apenas uma vez, usando uma junção interna para excluir as linhas que serão atualizadas. Após a exclusão das linhas, elas são substituídas por novas linhas por uma única operação de inserção da tabela de preparação. Use este método se todos os itens a seguir forem verdadeiros: + Sua tabela de destino e sua tabela de preparação contêm as mesmas colunas. + Você pretende substituir todos os dados nas colunas da tabela de destino por todas as colunas da tabela de preparação. + Você utilizará todas as linhas da tabela de preparação na mesclagem. Se qualquer um desses critérios não se aplicar, use o “Método de mesclagem 2: especificação de uma lista de colunas sem usar MERGE”, descrito na seção a seguir. Se você não vai usar todas as linhas da tabela de preparação, filtre as instruções DELETE e INSERT usando uma cláusula WHERE para ignorar linhas que não estejam sendo alteradas. No entanto, se a maioria das linhas da tabela de preparação não participará da mesclagem, recomendamos executar um UPDATE e um INSERT em etapas separadas, conforme descrito posteriormente nesta seção. ## Método de mesclagem 2: especificação de uma lista de colunas sem usar MERGE Use este método para atualizar colunas específicas na tabela de destino em vez de substituir linhas inteiras. Este método leva mais tempo que o método anterior, pois ele requer uma etapa de atualização adicional e não usa o comando MERGE. Use este método se qualquer um dos itens a seguir for verdadeiro: + Não todas as colunas da tabela de destino devem ser atualizadas. + A maioria das linhas na tabela de preparação não serão usadas nas atualizações. **Topics** + [Método de mesclagem 1: substituição de linhas existentes](#merge-method-replace-existing-rows) + [Método de mesclagem 2: especificação de uma lista de colunas sem usar MERGE](#merge-method-specify-column-list) + [Criação de uma tabela de preparação temporária](merge-create-staging-table.md) + [Execução de uma operação de mesclagem com a substituição de linhas existentes](merge-replacing-existing-rows.md) + [Realizar uma operação de mesclagem especificando uma lista de colunas sem usar o comando MERGE](merge-specify-a-column-list.md) + [Exemplos de mesclagem](merge-examples.md) # Criação de uma tabela de preparação temporária A *tabela de preparação* é uma tabela temporária que guarda todos os dados que serão usados para fazer alterações na *tabela de destino*, incluindo atualizações e inserções. Uma operação de mesclagem requer uma junção entre a tabela de preparação e a tabela de destino. Para posicionar as linhas da mesclagem, defina a chave de distribuição da tabela de preparação na mesma coluna que a chave de distribuição da tabela de destino. Por exemplo, se a tabela de destino usa uma coluna de chave estrangeira como chave de distribuição, use a mesma coluna para a chave de distribuição da lista de preparação. Se você cria uma tabela de preparação usando um comando [CREATE TABLE LIKE](r_CREATE_TABLE_NEW.md#create-table-like), a tabela de preparação herda a chave de distribuição da tabela pai. Se você utiliza uma instrução CREATE TABLE AS, a nova tabela não herda a chave de distribuição. Para obter mais informações, consulte . [Distribuição de dados para otimização de consultas](t_Distributing_data.md) Se a chave de distribuição não é a mesma que a chave primária e a chave de distribuição não é atualizada como parte da operação de mesclagem, adicione um predicado de junção redundante nas colunas de chave de distribuição para permitir uma junção colocada. Por exemplo: ``` where target.primarykey = stage.primarykey and target.distkey = stage.distkey ``` Para verificar se consulta usará uma junção colocada, execute a consulta com [EXPLAIN](r_EXPLAIN.md) e verifique DS\$1DIST\$1NONE em todas as junções. Para obter mais informações, consulte . [Avaliação do plano de consulta](c_data_redistribution.md) # Execução de uma operação de mesclagem com a substituição de linhas existentes Ao executar a operação de mesclagem detalhada no procedimento, coloque todas as etapas, exceto de criação e exclusão da tabela de preparação temporária, em uma única transação. A transação será revertida se ocorrer uma falha na etapa. O uso de uma única transação também reduz o número de confirmações, que economiza tempo e recursos. **Para executar uma operação de mesclagem com a substituição de linhas existentes** 1. Crie uma tabela de preparação e preencha-a com os dados a serem mesclados, conforme exibido no seguinte pseudocódigo. ``` CREATE temp table stage (like target); INSERT INTO stage SELECT * FROM source WHERE source.filter = 'filter_expression'; ``` 1. Use MERGE para realizar uma junção interna com a tabela de preparação e atualizar as linhas da tabela de destino que correspondem à tabela de preparação e, depois, insira todas as linhas restantes na tabela de destino que não correspondam à tabela de preparação. Recomendamos que você execute as operações de atualização e inserção em um único 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. Descarte a tabela de preparação. ``` DROP TABLE stage; ``` # Realizar uma operação de mesclagem especificando uma lista de colunas sem usar o comando MERGE Ao executar a operação de mesclagem detalhada no procedimento, coloque todas as etapas em uma única transação. A transação será revertida se ocorrer uma falha na etapa. O uso de uma única transação também reduz o número de confirmações, que economiza tempo e recursos. **Para executar uma operação de mesclagem através da especificação de uma lista de colunas** 1. Coloque toda a operação em um único bloco de transações. ``` BEGIN transaction; … END transaction; ``` 1. Crie uma tabela de preparação e preencha-a com os dados a serem mesclados, conforme exibido no seguinte pseudocódigo. ``` create temp table stage (like target); insert into stage select * from source where source.filter = 'filter_expression'; ``` 1. Atualize a tabela de destino usando um junção interna com a tabela de preparação. + Na cláusula UPDATE, liste explicitamente as colunas a serem atualizadas. + Execute uma junção interna com a tabela de preparação. + Se a chave de distribuição for diferente da chave primária e a chave de distribuição não estiver sendo atualizada, adicione uma junção redundante à chave de distribuição. Para verificar se consulta usará uma junção colocada, execute a consulta com [EXPLAIN](r_EXPLAIN.md) e verifique DS\$1DIST\$1NONE em todas as junções. Para obter mais informações, consulte . [Avaliação do plano de consulta](c_data_redistribution.md) + Se sua tabela de destino for classificada por timestamp, adicione um predicado para tirar proveito das varreduras de intervalo restrito na tabela de destino. Para obter mais informações, consulte [Práticas recomendadas do Amazon Redshift para criar consultas](c_designing-queries-best-practices.md). + Se você não pretende usar todas as linhas na mesclagem, adicione uma cláusula para filtrar as linhas que precisam ser alteradas. Por exemplo, adicione um filtro de desigualdade em uma ou mais colunas para excluir as linhas que não alteraram. + Coloque as operações de atualização, exclusão e inserção em um único bloco de transações de forma que, se houver um problema, tudo seja revertido. Por exemplo: ``` 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. Exclua linhas indesejadas da tabela de preparação usando um junção interna com a tabela de destino. Algumas linhas na tabela de destino já correspondem a linhas na tabela de preparação e outras foram atualizadas na etapa anterior. Em ambos os casos, elas não são necessárias para a inserção. ``` delete from stage using target where stage.primarykey = target.primarykey; ``` 1. Insira as linhas remanescentes da tabela de preparação. Use a mesma lista de coluna na cláusula VALUES que você usou na instrução UPDATE da etapa dois. ``` insert into target (select col1, col2, 'expression' from stage); end transaction; ``` 1. Descarte a tabela de preparação. ``` drop table stage; ``` # Exemplos de mesclagem Os seguintes exemplos executam uma mesclarem para atualizar as tabela SALES. O primeiro exemplo usa o método mais simples de excluir a tabela de destino e depois inserir todas as linhas da tabela de preparação. O segundo exemplo exige a atualização de colunas selecionadas da tabela de destino, portanto ele inclui uma etapa de atualização adicional. O [Exemplos de mesclagem](#merge-examples) usa um exemplo de conjunto de dados para o Amazon Redshift, chamado conjunto de dados TICKIT. Como pré-requisito, você pode configurar as tabelas e os dados do TICKIT seguindo as instruções disponíveis no guia [Conceitos básicos das tarefas comuns do banco de dados](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Informações mais detalhadas sobre o exemplo de conjunto de dados estão disponíveis em [Exemplo de banco de dados](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). **Amostra de fonte de dados de mesclagem** Os exemplos nesta seção precisam de uma amostra de fonte de dados que inclua atualizações e inserções. Para os exemplos, criaremos uma tabela de amostra chamada SALES\$1UPDATE usando dados da tabela SALES. Preencheremos a nova tabela com dados aleatórios que representam novas atividades de vendas para dezembro. Usaremos a tabela de amostra SALES\$1UPDATE para criar a tabela de preparação nos exemplos a seguir. ``` -- 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; ``` **Exemplo de uma mesclagem que substitui linhas com base em chaves correspondentes** O seguinte script usa a tabela SALES\$1UPDATE para executar uma operação de mesclagem na tabela SALES com novos dados para a atividade de vendas de dezembro. Este exemplo substitui as linhas na tabela SALES que têm atualizações. Para este exemplo, atualizaremos as colunas qtysold e pricepaid, deixando comission e saletime inalteradas. ``` 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); ``` **Exemplo de uma mesclagem que especifica uma lista de colunas sem usar MERGE** O seguinte exemplo executa uma operação de mesclarem para atualizar SALES com novos dados para a atividade de vendas de dezembro. Precisamos de dados de amostra que incluam atualizações e inserções, assim como linhas que não alteraram. Para este exemplo, queremos atualizar as colunas QTYSOLD e PRICEPAID, deixando COMMISSION e SALETIME inalteradas. O seguinte script usa a tabela SALES\$1UPDATE para executar uma operação de mesclagem na tabela 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; ``` # Execução de uma cópia profunda Uma cópia profunda recria e preenche novamente uma tabela usando uma inserção em massa, que classifica automaticamente a tabela. Se uma tabela tem uma grande região não classificada, uma cópia profunda é muito mais rápida que um vacuum. Recomendamos que você só faça atualizações simultâneas durante uma operação de cópia profunda se conseguir rastreá-las. Depois que o processo for concluído, mova as atualizações delta para a nova tabela. Uma operação VACUUM oferece suporte para atualizações simultâneas automaticamente. Você pode escolher um dos seguintes métodos para criar uma cópia da tabela original: + Use o DDL da tabela original. Se CREATE TABLE DDL estiver disponível, este é o método preferido e mais rápido. Se você criar uma nova tabela, você pode especificar todos os atributos da tabela e da coluna, incluindo a chave primária e chaves estrangeiras. É possível encontrar o DDL original usando a função SHOW TABLE. + Use CREATE TABLE LIKE. Se o DDL original não estiver disponível, você pode usar CREATE TABLE LIKE para recriar a tabela original. A nova tabela herda a codificação, a chave de distribuição, a chave de classificação e os atributos não nulos da tabela pai. A nova tabela não herda os atributos de chave primária e chaves estrangeiras da tabela pai, mas você pode adicioná-los usando [ALTER TABLE](r_ALTER_TABLE.md). + Crie uma tabela temporária e trunque a tabela original. Se você precisar manter os atributos da chave primária e da chave externa da tabela principal. Se a tabela principal tiver dependências, você poderá usar CREATE TABLE... AS (CTAS) para criar uma tabela temporária. Depois, trunque a tabela original e preencha-a a partir da tabela temporária. O uso de uma tabela temporária aprimora a performance significativamente comparado ao uso de uma tabela permanente, mas há risco de perda de dados. Uma tabela temporária é automaticamente descartada no final da sessão na qual ela é criada. TRUNCATE confirma imediatamente, mesmo se ele estiver dentro de bloco de transações. Se TRUNCATE tiver êxito, mas a sessão for concluída antes da conclusão de INSERT subsequente, os dados serão perdidos. Se a perda de dados for inaceitável, use uma tabela permanente. Depois de criar uma cópia de uma tabela, talvez seja necessário conceder acesso à nova tabela. Você pode usar [GRANT](r_GRANT.md) para definir privilégios de acesso. Para visualizar e conceder todos os privilégios de acesso de uma tabela, você deve ser um dos seguintes: + Um superusuário. + O proprietário da tabela que você deseja copiar. + Um usuário com o privilégio ACCESS SYSTEM TABLE para ver os privilégios da tabela e com o privilégio de concessão para todas as permissões relevantes. Além disso, talvez seja necessário conceder permissão de uso para o esquema em que sua cópia profunda está inserida. A concessão de permissão de uso será necessária se o esquema da cópia profunda for diferente do esquema da tabela original e também não for o esquema `public`. Para visualizar e conceder os privilégios de acesso de uma tabela, você deve ser um dos seguintes: + Um superusuário. + Um usuário que possa conceder a permissão USAGE para o esquema da cópia profunda. **Para realizar uma cópia profunda usando o DDL da tabela original** 1. (Opcional) Recrie o DDL da tabela executando um script chamado `v_generate_tbl_ddl`. 1. Crie uma cópia da tabela usando o CREATE TABLE DDL original. 1. Use uma instrução INSERT INTO… SELECT para povoar a cópia com dados da tabela original. 1. Confira as permissões concedidas na tabela antiga. Você pode ver essas permissões na visualização do sistema SVV\$1RELATION\$1PRIVILEGES. 1. Se necessário, conceda as permissões da tabela antiga para a nova tabela. 1. Conceda permissão de uso a cada grupo e usuário que tenha privilégios na tabela original. Essa etapa não será necessária se sua tabela de cópia profunda estiver no esquema `public` ou estiver no mesmo esquema da tabela original. 1. Descarte a tabela original. 1. Use uma instrução ALTER TABLE para renomear a cópia com o nome da tabela original. O exemplo a seguir executa uma cópia profunda na tabela SAMPLE usando uma duplicação de SAMPLE chamada sales\$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; ``` **Para realizar uma cópia profunda usando CREATE TABLE LIKE** 1. Crie uma nova tabela usando CREATE TABLE LIKE. 1. Use uma instrução INSERT INTO… SELECT para copiar as linhas da tabela atual para a nova tabela. 1. Confira as permissões concedidas na tabela antiga. Você pode ver essas permissões na visualização do sistema SVV\$1RELATION\$1PRIVILEGES. 1. Se necessário, conceda as permissões da tabela antiga para a nova tabela. 1. Conceda permissão de uso a cada grupo e usuário que tenha privilégios na tabela original. Essa etapa não será necessária se sua tabela de cópia profunda estiver no esquema `public` ou estiver no mesmo esquema da tabela original. 1. Descarte a tabela atual. 1. Use uma instrução ALTER TABLE para renomear a nova tabela com o nome da tabela original. O exemplo a seguir executa uma cópia profunda na tabela SAMPLE usando 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; ``` **Para executar uma cópia profunda criando uma tabela temporária e truncando a tabela original** 1. Use CREATE TABLE AS para criar uma tabela temporária com as linhas da tabela original. 1. Trunque a tabela atual. 1. Use uma instrução INSERT INTO… SELECT para copiar as linhas da tabela temporária para a tabela original. 1. Descarte a tabela temporária. O exemplo a seguir executa uma cópia profunda na tabela SALES criando uma tabela temporária e truncando a tabela original. Como a tabela original permanece, você não precisa conceder permissões à tabela de cópia. ``` --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; ``` # Análise de tabelas A operação ANALYZE atualiza os metadados estatísticos que o planejador de consulta utiliza para escolher os planos ideais. Na maioria dos casos, não é preciso executar explicitamente o comando ANALYZE. O Amazon Redshift monitora as alterações no workload e atualiza automaticamente as estatísticas em segundo plano. Além disso, o comando COPY executa uma análise automaticamente quando carrega dados em uma tabela vazia. Para analisar explicitamente uma tabela ou o banco de dados inteiro, execute o comando [ANALYZE](r_ANALYZE.md). ## Análise automática O Amazon Redshift monitora continuamente seu banco de dados e executa automaticamente as operações de análise em segundo plano. Para minimizar o impacto na performance do sistema, a análise automática é executada durante os períodos em que os workloads são leves. A análise automática está habilitada por padrão. Para desativar a análise automática, defina o parâmetro `auto_analyze` como **false** modificando o grupo de parâmetros de seu cluster. Para reduzir o tempo de processamento e melhorar a performance geral do sistema, o Amazon Redshift ignora a análise automática de qualquer tabela em que a extensão das modificações seja pequena. Uma operação de análise ignora tabelas com estatísticas atualizadas. Se você executar ANALYZE como parte de seu fluxo de trabalho de extração, transformação e carregamento (ETL), a análise automática ignorará as tabelas com estatísticas atuais. Da mesma forma, um ANALYZE explícito ignorará as tabelas quando a análise automática atualizar as estatísticas da tabela. ## Análise de novos dados da tabela Por padrão, o comando COPY executa um ANALYZE após carregar dados em uma tabela vazia. Você pode forçar um ANALYZE mesmo se uma tabela estiver vazia definindo STATUPDATE ON. Se você especificar STATUPDATE OFF, nenhum ANALYZE será realizado. Somente o proprietário da tabela ou um superusuário podem executar o comando ANALYZE ou executar o comando COPY com STATUPDATE definida como ON. O Amazon Redshift também analisa novas tabelas que você cria com os seguintes comandos: + CREATE TABLE AS (CTAS) + CREATE TEMP TABLE AS + SELECT INTO O Amazon Redshift retorna uma mensagem de aviso quando você executa uma consulta em uma nova tabela que não foi analisada depois que seus dados foram carregados inicialmente. Nenhum aviso ocorre quando você consulta uma tabela após uma atualização ou carregamento subsequente. A mesma mensagem de aviso é retornada quando você executa o comando EXPLAIN em uma consulta que se refere a tabelas que não foram analisadas. Sempre que a adição de dados a uma tabela não vazia alterar significativamente o tamanho da tabela, é possível atualizar estatísticas explicitamente. Isso é feito com a execução de um comando ANALYZE ou usando a opção STATUPDATE ON com o comando COPY. Para visualizar detalhes sobre o número de linhas que foram inseridas ou excluídas desde o último ANALYZE, consulte a tabela de catálogo do sistema [PG\$1STATISTIC\$1INDICATOR](r_PG_STATISTIC_INDICATOR.md). Você pode especificar o escopo do comando [ANALYZE](r_ANALYZE.md) para um dos seguintes: + Todo o banco de dados atual + Uma tabela única + Uma ou mais colunas específicas em uma tabela única + Colunas que provavelmente serão usadas como predicados em consultas O comando ANALYZE obtém um exemplo de linhas da tabela, faz alguns cálculos e salva as estatísticas de coluna resultantes. Por padrão, o Amazon Redshift executa uma passagem de amostra para a coluna DISTKEY e outra passagem de amostra para todas as outras colunas na tabela. Se você quiser gerar estatísticas para um subconjunto de colunas, você pode especificar uma lista de colunas separadas por vírgula. É possível executar ANALYZE com a cláusula PREDICATE COLUMNS para ignorar colunas que não são usadas como predicados. ANALYZE são operações com uso intenso de recursos, portanto execute as operações somente em tabelas e colunas que realmente exigem atualizações de estatísticas. Você não precisa analisar regularmente todas as colunas em todas as tabelas ou no mesmo agendamento. Se os dados são alterados substancialmente, analise as colunas que são usadas frequentemente para o seguinte: + Operações de agrupamento e classificação + Junções + Predicados de consultas Para reduzir o tempo de processamento e melhorar a performance geral do sistema, o Amazon Redshift ignora ANALYZE para qualquer tabela que tenha uma baixa porcentagem de linhas alteradas, conforme determinado pelo parâmetro [analyze\$1threshold\$1percent](r_analyze_threshold_percent.md). Por padrão, o limite de análise é definido como 10 por cento. Você pode alterar o limite de análise para a sessão atual executando um comando [SET](r_SET.md). Colunas menos propensas a exigir análises frequentes são aquelas que representam fatos e medidas e quaisquer atributos relacionado que nunca são realmente consultados, tais como grandes colunas VARCHAR. Por exemplo, considere a tabela LISTING no banco de dados 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 essa tabela for carregada todos os dias com um grande número de novos registros, a coluna LISTID, que é usada frequentemente em consultas como uma chave de junção, deve ser analisada regularmente. Se TOTALPRICE e LISTTIME forem restrições frequentemente usadas em consultas, você pode analisar essas colunas e a chave de distribuição todos os dias úteis. ``` analyze listing(listid, totalprice, listtime); ``` Suponha que os vendedores e eventos no aplicativo sejam muito mais estáticos e os IDs de data se refiram a um conjunto fixo de dias que abrangem apenas dois ou três anos. Nesse caso, os valores exclusivos dessas colunas não são alterados significativamente. Contudo, o número de instâncias de cada valor exclusivo aumentará continuamente. Além disso, considere o caso em que as medidas NUMTICKETS e PRICEPERTICKET são consultadas raramente em comparação à coluna TOTALPRICE. Nesse caso, você pode executar o comando ANALYZE em toda a tabela todos os finais de semana para atualizar as estatísticas para as cinco colunas que não são analisadas diariamente: **Colunas de predicados** Como uma alternativa conveniente para a especificação de uma lista de colunas, você poderá escolher analisar apenas as colunas que provavelmente serão usadas como predicados. Quando você executa uma consulta, todas as colunas que são usadas em uma cláusula de junção, condição de filtro ou group by são marcadas como colunas de predicados no catálogo de sistema. Quando você executa ANALYZE com a cláusula PREDICATE COLUMNS, a operação de análise inclui somente as colunas que atendem aos seguintes critérios: + A coluna é marcada como uma coluna de predicado. + A coluna é uma chave de distribuição. + A coluna faz parte de uma chave de classificação. Se nenhuma das colunas de uma tabela está marcada como predicado, ANALYZE inclui todas as colunas, mesmo quando PREDICATE COLUMNS é especificado. Se nenhuma coluna está marcada como coluna de predicado, pode ser que a tabela ainda não tenha sido consultada. Você pode optar por usar PREDICATE COLUMNS quando o padrão de consulta de seu workload é relativamente estável. Quando o padrão de consulta é variável, com diferentes colunas sendo frequentemente usadas como predicados, o uso de PREDICATE COLUMNS pode temporariamente resultar em estatísticas obsoletas. Estatísticas obsoletas podem ocasionar planos de ambiente de tempo de execução de consulta pouco satisfatórios e tempos de ambiente de tempo de execução longos. Contudo, na próxima vez que você executar ANALYZE usando PREDICATE COLUMNS, as novas colunas de predicado são incluídas. Para visualizar detalhes de colunas de predicado, use o seguinte SQL para criar uma exibição chamada 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; ``` Suponha que você execute a consulta a seguir na tabela LISTING. Observe que LISTID, LISTTIME e EVENTID são usados nas cláusulas de junção, filtro e group by. ``` 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 você consulta a exibição PREDICATE\$1COLUMNS, conforme exibido no seguinte exemplo, você vê que LISTID, EVENTID e LISTTIME, estão marcadas como colunas de predicado. ``` 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 ``` Manter as estatísticas atualizadas melhora a performance das consultas, permitindo que o planejador de consultas escolha os planos ideais. O Amazon Redshift atualiza as estatísticas automaticamente em segundo plano, e você pode executar explicitamente o comando ANALYZE. Se você optar por executar explicitamente ANALYZE, faça o seguinte: + Execute o comando ANALYZE antes de executar consultas. + Execute o comando ANALYZE nos bancos de dados rotineiramente ao final de cada ciclo regular de carregamento ou atualização. + Execute o comando ANALYZE em todas as tabelas novas que você criar e em todas as tabelas ou colunas existentes submetidas a alterações significativas. + Considere executar operações ANALYZE em diferentes agendamentos para os diferentes tipos de tabelas e colunas, dependendo de seu uso em consultas e de sua propensão a alterações. + Para economizar tempo e recursos do cluster, use a cláusula PREDICATE COLUMNS ao executar ANALYZE. Você não precisa executar explicitamente o comando ANALYZE depois de restaurar um snapshot em um cluster provisionado ou namespace sem servidor, nem depois de retomar um cluster provisionado pausado. O Amazon Redshift preserva as informações da tabela do sistema nesses casos, tornando desnecessários os comandos manuais ANALYZE. O Amazon Redshift continuará a executar operações de análise automática conforme necessário. Uma operação de análise ignora tabelas com estatísticas atualizadas. Se você executar ANALYZE como parte de seu fluxo de trabalho de extração, transformação e carregamento (ETL), a análise automática ignorará as tabelas com estatísticas atuais. Da mesma forma, um ANALYZE explícito ignorará as tabelas quando a análise automática atualizar as estatísticas da tabela. ## Histórico do comando ANALYZE É útil saber quando o último comando ANALYZE foi executado em uma tabela ou banco de dados. Quando um comando ANALYZE é executado, o Amazon Redshift executa várias consultas semelhantes a esta: ``` padb_fetch_sample: select * from table_name ``` Consultar STL\$1ANALYZE para visualizar o histórico de operações de análise. Se o Amazon Redshift analisa uma tabela usando análise automática, a coluna `is_background` é definida como `t` (true). Caso contrário, ele será definido como `f` (falso). O exemplo a seguir une a STV\$1TBL\$1PERM para mostrar o nome da tabela e os detalhes do ambiente de tempo de execução. ``` 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) ``` Como alternativa, você pode executar uma consulta mais complexa que retorna todas as instruções executadas em todas as transações concluídas que incluíram um 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 de tabelas O Amazon Redshift pode classificar e executar automaticamente uma operação VACUUM DELETE nas tabelas em segundo plano. Para limpar tabelas após um carregamento ou uma série de atualizações incrementais, você também pode executar o comando [VACUUM](r_VACUUM_command.md) no banco de dados inteiro ou em tabelas individuais. **nota** Somente usuários com as permissões de tabela necessárias podem efetivamente limpar uma tabela. Se VACUUM for executado sem as permissões necessárias de tabela, a operação será concluída com êxito, mas sem efeito. Para obter uma lista das permissões de tabela válidas para executar efetivamente VACUUM, consulte [VACUUM](r_VACUUM_command.md). Por esse motivo, é recomendável limpar tabelas individuais conforme necessário. Também recomendamos essa abordagem porque limpar todo o banco de dados é uma operação potencialmente cara. ## Classificação automática de tabela O Amazon Redshift classifica os dados automaticamente em segundo plano para manter os dados da tabela na ordem de sua chave de classificação. O Amazon Redshift mantém o controle de suas consultas de verificação para determinar quais seções da tabela se beneficiarão com a classificação. O Amazon Redshift também acompanha as consultas de verificação de clusters de escalabilidade simultânea. Para arquiteturas de vários clusters usando o compartilhamento de dados do Amazon Redshift, o Amazon Redshift também acompanha consultas de verificação originadas de clusters/grupos de trabalho de consumidores em sua data mesh, incluindo clusters/grupos de trabalho em diferentes regiões. As estatísticas de verificação do cluster principal, dos clusters de escalabilidade de simultaneidade e dos clusters de consumidor são agregadas para determinar quais seções da tabela se beneficiarão da classificação. Dependendo da carga no sistema, o Amazon Redshift inicia automaticamente a classificação. A classificação automática reduz a necessidade de executar o comando VACUUM para manter os dados na ordem da chave de classificação. Se for necessário classificar os dados totalmente na ordem da chave de classificação, por exemplo, depois de um grande carregamento de dados, você ainda poderá executar o comando VACUUM manualmente. Para determinar se a tabela terá algum benefício com a execução de VACUUM SORT, monitore a coluna `vacuum_sort_benefit` em [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). O Amazon Redshift rastreia consultas de varredura que usam a chave de classificação em cada tabela. O Amazon Redshift estima a porcentagem máxima de melhoria na verificação e filtragem de dados para cada tabela (se a tabela foi totalmente classificada). A estimativa é visível na coluna `vacuum_sort_benefit` em [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Você pode usar essa coluna, junto com a coluna `unsorted`, para determinar quando as consultas podem se beneficiar da execução manual de VACUUM SORT em uma tabela. A coluna `unsorted` reflete a ordem de classificação física de uma tabela. A coluna `vacuum_sort_benefit` especifica o impacto da classificação de uma tabela executando manualmente VACUUM SORT. Por exemplo, considere a seguinte consulta: ``` 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 ``` Para a tabela “sales”, embora a tabela esteja \$186% não classificada fisicamente, o impacto da performance da consulta na tabela que está 86% não classificada é de apenas 5%. Isso pode ocorrer porque apenas uma parte pequena da tabela é acessada por consultas ou porque muito poucas consultas acessaram a tabela. No caso da tabela “event”, a tabela está \$145% não classificada fisicamente. Mas o impacto da performance da consulta de 67% indica que uma parte maior da tabela foi acessada por consultas ou o número de consultas que acessaram a tabela era grande. A tabela “event” pode se beneficiar potencialmente da execução de VACUUM SORT. ## Exclusão de vacuum automática Ao executar uma exclusão, as linhas são marcadas para exclusão, mas não removidas. O Amazon Redshift executa automaticamente uma operação VACUUM DELETE em segundo plano com base no número de linhas excluídas nas tabelas de banco de dados. O Amazon Redshift programa o VACUUM DELETE para execução durante períodos de carga reduzida e pausa a operação durante períodos de alta carga. **Topics** + [Classificação automática de tabela](#automatic-table-sort) + [Exclusão de vacuum automática](#automatic-table-delete) + [Frequência de VACUUM](#vacuum-frequency) + [Estágio do classificação e estágio de mesclagem](#vacuum-stages) + [Limite de vacuum](#vacuum-sort-threshold) + [Tipos de vacuum](#vacuum-types) + [Minimizar tempos de limpeza](vacuum-managing-vacuum-times.md) ## Frequência de VACUUM Você deve limpar com a frequência necessária para manter a performance consistente de consulta. Considere esses fatores ao determinar com que frequência executar o comando VACUUM: + Execute VACUUM durante períodos em que você espera atividade mínima no cluster, tais como noites ou durante janelas designadas de administração do banco de dados. + Execute os comandos VACUUM fora das janelas de manutenção. Para obter mais informações, consulte [Agendamento em torno de janelas de manutenção](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html). + Uma grande região não classificada resulta em tempos mais longos de limpeza. Se você adiar a limpeza, ela levará mais tempo, pois mais dados precisam ser reorganizados. + VACUUM é uma operação uso intensivo de E/S, portanto quanto mais tempo sua limpeza levar para concluir, maior será o impacto sobre consultas simultâneas e outras operações de banco de dados em execução no seu cluster. + VACUUM leva mais tempo para tabelas que usam classificação intercalada. Para avaliar se tabelas intercaladas precisam ser reclassificadas, consulte a visualização [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). ## Estágio do classificação e estágio de mesclagem O Amazon Redshift realiza uma operação de vácuo em dois estágios: primeiro, ele classifica as linhas na região não classificada e, se necessário, mescla as linhas recém-classificadas no final da tabela com as linhas existentes. Ao limpar uma tabela grande, a operação de limpeza continua em uma série de etapas que consistem em classificações incrementais seguidas de mesclagens. Se a operação falhar ou se o Amazon Redshift ficar off-line durante a limpeza, a tabela ou o banco de dados parcialmente limpo estará em um estado consistente, mas você precisará reiniciar manualmente a operação de limpeza. As classificações incrementais serão perdidas, mas as linhas mescladas que foram confirmadas antes da falha não precisam ser limpas novamente. Se a região não classificada é grande, o tempo perdido pode ser significativo. Para obter mais informações sobre as etapas de classificação e mesclagem, consulte [Reduzir o volume de linhas mescladas](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows). Os usuários podem acessar tabelas enquanto elas estão sendo limpas. Você pode executar consultas e operações de gravação enquanto uma tabela está sendo limpa, mas quando DML e uma limpeza são executados simultaneamente, ambos podem levar mais tempo. Se você executar instruções UPDATE e DELETE durante uma limpeza, a performance do sistema pode ser reduzida. Mesclagens incrementais bloqueiam temporariamente operações UPDATE e DELETE simultâneas, e operações UPDATE e DELETE simultâneas, por usa vez, bloqueia as etapas de mesclagem incremental nas tabelas afetadas. As operações DDL, tal como ALTER TABLE, são bloqueadas até que a operação de limpeza termine com a tabela. **nota** Vários modificadores para VACUUM controlam a forma como ele funciona. Você pode usá-los para adaptar a operação de vácuo para a necessidade atual. Por exemplo, usando VACUUM RECLUSTER encurta a operação de vácuo não executando uma operação de mesclagem completa. Para obter mais informações, consulte [VACUUM](r_VACUUM_command.md). ## Limite de vacuum Por padrão, VACUUM ignora a fase de classificação para qualquer tabela em que mais de 95 por cento das linhas da tabela já estejam classificadas. Ignorar a fase de classificação pode melhorar significativamente a performance de VACUUM. Para alterar o limite de classificação padrão para uma única tabela, inclua o nome da tabela e o parâmetro TO *limite* PERCENT ao executar o comando VACUUM. ## Tipos de vacuum Para obter informações sobre os diferentes tipos de vácuo, consulte [VACUUM](r_VACUUM_command.md). # Minimizar tempos de limpeza O Amazon Redshift classifica os dados automaticamente e executa VACUUM DELETE em segundo plano. Isso reduz a necessidade de executar o comando VACUUM. O processo de limpeza pode ser demorado. Dependendo da natureza dos dados, recomendamos seguir as práticas nesta seção para minimizar os tempos de limpeza. **Topics** + [Decidir sobre a reindexação](#r_vacuum-decide-whether-to-reindex) + [Reduzir o tamanho da região não classificada](#r_vacuum_diskspacereqs) + [Reduzir o volume de linhas mescladas](#vacuum-managing-volume-of-unmerged-rows) + [Carregar os dados por ordem de chave de classificação](#vacuum-load-in-sort-key-order) + [Usar tabelas de séries temporais para reduzir os dados armazenados](#vacuum-time-series-tables) ## Decidir sobre a reindexação Frequentemente, você pode melhorar significativamente a performance da consulta usando um estilo intercalado de classificação, mas ao longo do tempo a performance pode se degradar se a distribuição de valores nas colunas de chaves de classificação alterar. Ao carregar inicialmente uma tabela intercalada vazia usando COPY ou CREATE TABLE AS, o Amazon Redshift constrói automaticamente o índice intercalado. Se você inicialmente carregar uma tabela intercalada usando INSERT, você precisa executar um VACUUM REINDEX posteriormente para inicializar o índice intercalado. Com o tempo, à medida que você adiciona linhas com novos valores de chave de classificação, a performance pode se degradar se a distribuição de valores nas colunas de chaves de classificação alterar. Se suas novas linhas caem principalmente no intervalo de valores de chave de classificação existente, você não precisa reindexar. Execute VACUUM SORT ONLY ou VACUUM FULL para restaurar a ordem de classificação. O mecanismo de consulta é capaz de usar a ordem de classificação para selecionar com eficiência quais blocos de dados devem ser varridos para processar uma consulta. Para uma classificação intercalada, o Amazon Redshift analisa os valores da coluna de chave de classificação para determinar a ordem de classificação ideal. Se a distribuição dos valores de chave muda ou é distorcida à medida que linhas são adicionadas, a estratégia de classificação não será mais ideal e o benefício de performance de classificação se degradará. Para reanalisar a distribuição de chaves de classificação, você pode executar um VACUUM REINDEX. A operação de reindexação consome tempo, portanto para decidir se uma tabela se beneficiará de uma de reindexação, consulte a exibição [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). Por exemplo, a seguinte consulta exibe os detalhes de tabelas que usam chaves de classificação intercaladas. ``` 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) ``` O valor para `interleaved_skew` é uma proporção que indica a quantidade de distorção. Um valor de 1 significa que não há distorção. Se a distorção for maior que 1,4, um VACUUM REINDEX melhorará a performance a menos que a distorção seja inerente ao conjunto subjacente. Você pode usar o valor de data em `last_reindex` para determinar quanto tempo se passou desde a última reindexação. ## Reduzir o tamanho da região não classificada A região não classificada aumenta quando você carrega grandes quantidades de novos dados em tabelas que já contêm dados ou quando você não limpa as tabelas como parte de suas operações de manutenção de rotina. Para evitar operações de limpeza de longa execução, use as seguintes práticas: + Execute operações de limpeza em uma programação regular. Se você carregar suas tabelas em pequenos incrementos (tal como atualizações diárias que representam uma pequena porcentagem do número total de linhas na tabela), a execução de VACUUM regularmente ajudará a garantir que operações individuais de limpeza ocorram rapidamente. + Execute o maior carregamento primeiro. Se você precisar carregar uma nova tabela com várias operações COPY, execute o maior carregamento primeiro. Quando você executa um carregamento inicial em uma tabela nova ou truncada, todos os dados são carregados diretamente na região classificada, portanto nenhuma limpeza é necessária. + Trunque uma tabela em vez de excluir todas as linhas. A exclusão de linhas de uma tabela não recupera o espaço que as linhas ocupavam até que você execute uma operação de limpeza; entretanto, truncar uma tabela esvazia a tabela e recupera o espaço em disco, portanto nenhuma limpeza é necessária. Como alternativa, descarte a tabela e volte a criá-la. + Trunque ou descarte tabelas de teste. Se você estiver carregando um pequeno número de linhas em uma tabela para fins de teste, não exclua as linhas quando tiver terminado. Em vez disso, trunque a tabela e recarregue essas linhas como parte da operação de carregamento de produção subsequente. + Execute uma cópia profunda. Se uma tabela que usa uma chave de classificação composta tem uma grande região não classificada, uma cópia profunda é muito mais rápida que um vacuum. Uma cópia profunda recria e preenche novamente uma tabela usando uma inserção em massa, que reclassifica a tabela automaticamente. Se uma tabela tem uma grande região não classificada, uma cópia profunda é muito mais rápida que um vacuum. A diferença é que você não pode realizar atualizações simultâneas durante uma operação de cópia profunda, o que pode ocorrer durante um vacuum. Para obter mais informações, consulte [Práticas recomendadas do Amazon Redshift para criar consultas](c_designing-queries-best-practices.md). ## Reduzir o volume de linhas mescladas Se uma operação de limpeza precisar mesclar novas linhas na região classificada de uma tabela, o tempo necessário para uma limpeza aumentará à medida que a tabela crescer. Você pode melhorar a performance da limpeza reduzindo o número de linhas que devem ser mescladas. Antes de uma limpeza, uma tabela consiste em uma região classificada no topo da tabela, seguida por uma região não classificada, que aumenta sempre que linhas são adicionadas ou atualizadas. Quando um conjunto de linhas é adicionado por uma operação COPY, o novo conjunto de linhas é classificado na chave de classificação à medida que é adicionado à região não classificada no final da tabela. As novas linhas são ordenadas dentro de seu próprio conjunto, mas não na região não classificada. O diagrama a seguir ilustra a região não classificada após duas operações COPY sucessivas, onde a chave de classificação é CUSTID. Por simplicidade, este exemplo mostra uma chave de classificação composta, mas os mesmos princípios se aplicam à chaves de classificação intercaladas, salvo que o impacto da região não classificada é maior para tabelas intercaladas. ![\[Uma tabela não classificada contendo registros de duas operações COPY.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/vacuum-unsorted-region.png) Uma limpeza restaura a ordem de classificação de uma tabela em duas etapas: 1. Classifique a região não classificada em uma região recém-classificada. A primeira etapa é relativamente barata, pois somente a região não classificada é regravada. Se o intervalo de valores de chave de classificação da região recém-classificada for maior que o intervalo existente, somente as novas linhas precisarão ser regravadas e a limpeza será concluída. Por exemplo, se a região classificada contém valores de ID de 1 a 500 e as operações copy subsequentes adicionam valores de chave maiores que 500, então somente a região não classificada precisa ser regravada. 1. Mesclagem da região recém-classificada com a região previamente classificada. Se as chaves na região classificada recentemente classificada sobrepõem-se às chaves da região classificada, VACUUM precisa mesclar as linhas. Começando no início da região recém-classificada (a chave de classificação mais baixa), a limpeza grava as linhas mescladas da região previamente classificada e a região recém classificada em um novo conjunto de blocos. A extensão com que o novo intervalo de chaves de classificação sobrepõe as chaves de classificação existentes determina a extensão na qual a região previamente classificada deve ser regravada. Se as chaves não classificadas estão espalhadas pelo intervalo de classificação existente, a limpeza pode precisar regravar porções existentes da tabela. O diagrama a seguir mostra como uma limpeza classificaria e mesclaria as linhas que são adicionadas em uma tabela em que CUSTID é a chave de classificação. Como cada operação copy adiciona um novo conjunto de linhas com valores de chave que se sobrepõem às chaves existente, quase toda a tabela precisa ser regravada. O diagrama mostra uma única classificação e mesclagem, mas na prática, uma grande limpeza consiste em uma serie de etapas de classificação e mesclagem incrementais. ![\[Uma operação VACUUM na tabela de exemplo em duas etapas. Primeiro, as novas linhas são classificadas e depois mescladas com as linhas existentes.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) Se o intervalo de chaves de classificação em um novo conjunto de linhas sobrepõe o intervalo de chaves existente, o custo da etapa de mesclagem continua crescendo na proporção do tamanho da tabela à medida que ela cresce, enquanto o custo da etapa de classificação permanece proporcional ao tamanho da região não classificada. Nesse caso, o custo da etapa de mesclagem ofusca o custo da etapa de classificação, conforme exibido no diagrama a seguir. ![\[Diagrama mostrando como o estágio de mesclagem torna-se mais caro quando novas linhas têm chaves de classificação sobrepostas às linhas existentes.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) Para determinar que proporção de uma tabela foi remesclada, consulte SVV\$1VACUUM\$1SUMMARY após a conclusão da operação de limpeza. A seguir consulta exibe os efeitos de seis limpezas consecutivas à medida que CUSTSALES cresceu ao longo do 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) ``` A coluna merge\$1increments fornece uma indicação da quantidade de dados que foram mesclados em cada operação de limpeza. Se o número de incrementos de mesclagem ao longo de limpezas consecutivas aumentar em proporção ao crescimento do tamanho da tabela, isso é uma indicação de que cada operação de limpeza está mesclando novamente um número crescente de linhas na tabela em decorrência da sobreposição das regiões classificadas existentes e novas. ## Carregar os dados por ordem de chave de classificação Se você carregar os dados na ordem da chave de classificação usando o comando COPY, poderá reduzir ou até mesmo eliminar a necessidade de limpeza. COPY adiciona automaticamente linhas novas à região classificada da tabela quando todas as seguintes opções são verdadeiras: + A tabela usa uma chave de classificação composta com somente uma coluna de classificação. + A coluna de classificação é NOT NULL. + A tabela está 100 por cento classificada ou vazia. + Todas as linhas novas são mais altas na ordem de classificação que as linhas existentes, incluindo as linhas marcadas para exclusão. Nesse caso, o Amazon Redshift usa os primeiros oito bytes da chave de classificação para determinar a ordem de classificação. + O comando COPY não aciona determinadas otimizações de carga. Ao carregar grandes volumes de dados, o Amazon Redshift pode otimizar a performance criando partições classificadas em vez de adicionar linhas à região classificada da tabela. Por exemplo, suponha que você tenha uma tabela que registre eventos de clientes usando um ID de cliente e hora. Se você classificar pelo ID de cliente, é provável que o intervalo de chaves de classificação de novas linhas adicionadas por carregamentos incrementais se sobreponha ao intervalo existente, conforme mostrado no exemplo anterior, resultando em uma operação de limpeza dispendiosa. Se você definir sua chave de classificação como uma coluna de carimbo de data/hora, suas novas linhas serão anexadas por ordem de classificação no final da tabela, conforme exibido no diagrama a seguir, reduzindo ou até eliminando a necessidade de limpeza. ![\[Uma tabela que usa uma coluna de carimbo de data/hora como chave de classificação e obtém novos registros que não precisam ser classificados.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## Usar tabelas de séries temporais para reduzir os dados armazenados Se você mantém dados para um período de rolamento, use uma série de tabelas, como o diagrama a seguir ilustra. ![\[Cinco tabelas com dados de cinco trimestres. A tabela mais antiga é excluída para manter um ano de tempo contínuo.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) Crie uma nova tabela sempre que você adicionar um conjunto de dados e, então, exclua a tabela mais velha da série. Você obtém um benefício duplo: + Você evita o custo adicional da exclusão das linhas, pois uma operação DROP TABLE é muito mais eficiente que um DELETE em massa. + Se as tabelas são classificadas por timestamp, nenhuma limpeza é necessária. Se cada tabela contém os dados para um mês, uma limpeza no máximo terá que regravar um mês de dados, mesmo que as tabelas não estejam classificadas por timestamp. Você pode criar uma exibição UNION ALL para uso reportando consultas que ocultam o fato de que os dados são armazenados em várias tabelas. Se uma consulta filtrar na chave de classificação, o planejador de consulta pode eficientemente ignorar todas as tabelas que não são usadas. Um UNION ALL pode ser menos eficiente para outros tipos de consultas, portanto você deve avaliar a performance de consultas no contexto de todas as consultas que utilizam as tabelas. # Gerenciamento de operações de gravação simultâneas Alguns aplicativos exigem não apenas consultas e o carregamentos simultâneos, mas também a capacidade de gravar em várias tabelas ou na mesma tabela simultaneamente. Nesse contexto, *simultaneamente* significa em sobreposição, e não programada para execução precisamente ao mesmo tempo. Duas transações são consideradas simultâneas se a segunda começar antes da confirmação da primeira transação. Operações simultâneas podem originar de sessões diferentes que são controladas pelo mesmo usuário ou por usuários diferentes. O Amazon Redshift oferece suporte a esses tipos de aplicativos, permitindo que as tabelas sejam lidas enquanto são carregadas ou modificadas de forma incremental. Consultas simplesmente observam a última versão confirmada, ou *snapshot* dos dados, em vez de esperar pela confirmação da próxima versão. Caso você queira que determinada consulta aguarde a confirmação de outra operação de gravação, você deve programá-la adequadamente. **nota** O Amazon Redshift oferece suporte a um comportamento de *confirmação automática* padrão em que cada comando SQL executado separadamente é confirmado individualmente. Se você inserir um conjunto de comandos em um bloco de transação (definido pelas instruções [BEGIN](r_BEGIN.md) e [END](r_END.md)), o bloco é confirmado como uma transação, de forma que você possa revertê-la se necessário. Exceções a esse comportamento são os comandos TRUNCATE e VACUUM, que confirmam automaticamente todas as alterações pendentes feitas na transação atual. Alguns clientes SQL emitem comandos BEGIN e COMMIT automaticamente, de modo que o cliente possa controlar se um grupo de instruções é executado como uma transação ou cada instrução individual é executada como sua própria transação. Verifique a documentação da interface que você está usando. Por exemplo, ao usar o driver Amazon Redshift JDBC, um `PreparedStatement` JDBC com uma string de consulta que contém vários comandos SQL (separados por ponto e vírgula) executa todas as instruções como uma única transação. Por outro lado, se você usar SQL Workbench/J, definir AUTO COMMIT ON e executar várias instruções, cada instrução será executada como sua própria transação. Os seguintes tópicos descrevem alguns dos conceitos chave e casos de uso que envolvem transações, snapshots de banco de dados, atualizações e comportamentos concorrentes. **Topics** + [Níveis de isolamento no Amazon Redshift](c_serial_isolation.md) + [Operações de gravação e de leitura/gravação](c_write_readwrite.md) + [Exemplos de gravações simultâneas](r_Serializable_isolation_example.md) + [Solucionar problemas de erros de isolamento serializável](c_serial_isolation-serializable-isolation-troubleshooting.md) # Níveis de isolamento no Amazon Redshift As operações de gravação simultâneas são aceitas no Amazon Redshift de forma protetora, usando bloqueios de gravação em tabelas e o princípio de *isolamento serializável*. O isolamento serializável preserva a ilusão de que uma transação em execução em uma tabela é a única transação em execução naquela tabela. Os bancos de dados do Amazon Redshift comportam operações de gravação simultâneas fazendo com que cada operação use a versão confirmada mais recente, ou o snapshot, de seus dados no início da transação. Um snapshot do banco de dados é criado em uma transação na primeira ocorrência da maioria das instruções SELECT, comandos DML tais como COPY, DELETE, INSERT, UPDATE e TRUNCATE, e após os seguintes comandos DDL: + ALTER TABLE (para adicional ou descartar colunas) + CRIAR TABELA + DESCARTAR TABELA + TRUNCATE TABLE Nenhuma outra transação consegue alterar esse snapshot, o que significa que as transações são isoladas umas das outras. Ou seja, as transações simultâneas são invisíveis entre si; não podem detectar as alterações uma das outras. Qualquer execução simultânea de transações deve produzir os mesmos resultados que a execução em série dessas transações. Se nenhuma execução serial dessas transações pode produzir os mesmos resultados, a transação que executa uma instrução que pode quebrar a capacidade de serializar é interrompida e revertida. Por exemplo, suponha que um usuário tente executar duas transações simultâneas, T1 e T2. A execução de T1 e T2 deve produzir os mesmos resultados de pelo menos um dos seguintes casos: + T1 e T2 são executadas em série nessa ordem. + T2 e T1 são executadas em série nessa ordem. Os níveis de isolamento no Amazon Redshift evitam os seguintes problemas: + Leituras sujas: uma leitura suja ocorre quando uma transação lê dados que ainda não foram confirmados. Por exemplo, suponha que a transação 1 atualize uma linha. A transação 2 lê a linha atualizada antes que T1 confirme a atualização. Se T1 reverter a alteração, T2 terá lido dados em linhas não confirmadas que o Amazon Redshift agora considera que nunca existiram. + Leituras não repetíveis: uma leitura não repetível ocorre quando uma única transação lê a mesma linha duas vezes, mas recebe dados diferentes a cada vez. Por exemplo, digamos que a transação 1 leia uma linha. A transação 2 atualiza ou exclui essa linha e confirma a atualização ou exclusão. Se T1 reler a linha, recuperará valores de linha diferentes ou descobrirá que a linha foi excluída. + Fantasmas: fantasma é uma linha que corresponde aos critérios de pesquisa, mas não é vista inicialmente. Por exemplo, suponha que a transação 1 leia um conjunto de linhas que atenda aos seus critérios de pesquisa. A transação 2 gera uma nova linha em uma instrução UPDATE ou INSERT que corresponda aos critérios de pesquisa para T1. Se T1 executar novamente sua instrução de pesquisa, ele receberá um conjunto diferente de linhas. ## Isolamento SNAPSHOT e SERIALIZABLE Os isolamentos SNAPSHOT e SERIALIZABLE são os dois níveis de isolamento serializáveis disponíveis no Amazon Redshift. O isolamento SNAPSHOT é o nível de isolamento padrão ao criar clusters provisionados e grupos de trabalho sem servidor, permitindo processar volumes maiores de dados do que o isolamento SERIALIZABLE em menos tempo. O isolamento SERIALIZABLE leva mais tempo, mas implementa restrições mais rígidas em transações simultâneas. Esse nível de isolamento evita problemas, como anomalias de distorção de gravação, permitindo que apenas uma transação seja confirmada, enquanto cancela todas as outras transações simultâneas com um erro de violação de isolamento serializável. Veja a seguir um exemplo de cronograma de como duas operações de gravação simultâneas seriam tratadas ao usar o isolamento SNAPSHOT. A declaração UPDATE de cada usuário pode ser confirmada porque ela não entra em conflito ao tentar atualizar as mesmas linhas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_serial_isolation.html) Se o mesmo cenário for executado usando o isolamento serializável, o Amazon Redshift encerrará o usuário 2 devido a uma violação serializável e retornará um erro `1023`. Para obter mais informações, consulte [Solucionar problemas de erros de isolamento serializável](c_serial_isolation-serializable-isolation-troubleshooting.md). Nesse caso, somente o usuário 1 pode confirmar com sucesso. ## Considerações Ao usar os níveis de isolamento no Amazon Redshift, pense no seguinte: + Consulte a visualização do catálogo STV\$1DB\$1ISOLATION\$1LEVEL para visualizar o nível de isolamento que seu banco de dados está usando. Para obter mais informações, consulte [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md). + Consulte a visualização PG\$1DATABASE\$1INFO para ver quantas transações simultâneas são aceitas em seu banco de dados. Para obter mais informações, consulte [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + As tabelas de catálogo de sistema (PG) e outras tabelas de sistema do Amazon Redshift não são bloqueadas em uma transação. Portanto, alterações nos objetos do banco de dados decorrentes de operações DDL e TRUNCATE são visíveis na confirmação para quaisquer transações simultâneas. Por exemplo, suponha que a tabela A exista no banco de dados quando duas transações simultâneas, T1 e T2, começam. Suponha que T2 retorna uma lista de tabelas selecionando na tabela de catálogo PG\$1TABLES. Em seguida, T1 descarta a tabela A e confirmações e, em seguida, T2 lista as tabelas novamente. A tabela A agora não está mais listada. Se T2 tentar consultar a tabela descartada, o Amazon Redshift retornará um erro "relação não existe". A consulta de catálogo que retorna a lista de tabelas para T2 ou verifica se a tabela A existe não está sujeita às mesmas regras de isolamento que as operações realizadas nas tabelas do usuário. Transações para atualizações dessas tabelas são executadas em um modo de isolamento de leitura confirmada. + As tabelas de catálogo com prefixo PG não aceitam o isolamento SNAPSHOT. # Operações de gravação e de leitura/gravação Você pode gerenciar o comportamento específico de operações simultâneas de gravação decidindo quando e como executar diferentes tipos de comandos. Os seguintes comandos são relevantes para esta discussão: + Comandos COPY, que executam carregamentos (iniciais ou incrementais) + Comandos INSERT que anexam uma ou mais linhas de cada vez + Comandos UPDATE, que modificam linhas existentes + Comandos DELETE, que removem linhas As operações COPY e INSERT são operações de gravação pura. As operações DELETE e UPDATE são operações de leitura/gravação (para que as linhas sejam excluídas ou atualizadas, elas devem ser lidas primeiro). Os resultados de operações simultâneas de gravação dependem dos comandos específicos que estão sendo executados simultaneamente. Operações UPDATE e DELETE comportam-se de maneira diferente, pois elas dependem de uma leitura inicial da tabela antes de realizar qualquer gravação. Considerando que transações simultâneas são invisíveis entre si, operações de UPDATE e DELETE devem ler o snapshot dos dados da última confirmação. Quando a primeira operação UPDATE ou delete libera seu bloqueio, a segunda operação UPDATE ou DELETE precisa determinar se os dados com os quais ela vai trabalhar são potencialmente obsoletos. Eles não serão obsoletos, pois a segunda transação não obtém seu snapshot dos dados até depois que a primeira transação tenha liberado seu bloqueio. ## Possível situação de deadlock para transações simultâneas de gravação envolvendo várias tabelas Quando transações envolvem atualizações de mais que uma tabela, sempre existe a possibilidade de que as transações em execução simultânea fiquem com deadlocks quando ambas tentam gravar no mesmo conjunto de tabelas. Uma transação libera todos os seus bloqueios de tabela de uma só vez ao confirmar ou reverter; ela não libera os bloqueios um de cada vez. Por exemplo, suponha que as transações T1 e T2 comecem aproximadamente ao mesmo tempo. Se T1 começar a gravar na tabela A e T2 começar a gravar na tabela B, as duas transações poderão prosseguir sem conflito. No entanto, se T1 terminar de gravar na tabela A e precisar começar a gravar na tabela B, ela não poderá prosseguir porque T2 ainda manterá o bloqueio na B. Da mesma forma, se T2 terminar de gravar na tabela B e precisar começar a gravar na tabela A, ela não poderá prosseguir porque T1 ainda manterá o bloqueio na A. Como nenhuma das transações pode liberar seus bloqueios até a confirmação de todas as suas operações de gravação, nenhuma transação pode prosseguir. Para evitar esse tipo de deadlock, você precisa programar operações simultâneas de gravação cuidadosamente. Por exemplo, você deve sempre atualizar as tabelas na mesma ordem nas transações e, se estiver especificando bloqueios, bloquear as tabelas na mesma ordem antes de executar qualquer operação DML. ## Possível situação de deadlock para transações simultâneas de gravação envolvendo uma tabela Em um ambiente de isolamento de snapshot, podem ocorrer deadlocks na execução de transações de gravação simultâneas na mesma tabela. O deadlock de isolamento de snapshot ocorre quando declarações INSERT ou COPY simultâneas estão compartilhando um bloqueio e progredindo, e outra declaração precisa realizar uma operação (UPDATE, DELETE, MERGE ou DDL) que exija um bloqueio exclusivo na mesma tabela. Considere o seguinte cenário: Transação 1 (T1): ``` INSERT/COPY INTO table_A; ``` Transação 2 (T2): ``` INSERT/COPY INTO table_A; table_A ``` Um deadlock pode ocorrer quando várias transações com operações INSERT ou COPY estão sendo executadas simultaneamente na mesma tabela com um bloqueio compartilhado e uma dessas transações segue sua operação de gravação pura com uma operação que exija um bloqueio exclusivo, como uma declaração UPDATE, MERGE, DELETE ou DDL. Para evitar o deadlock nessas situações, é possível separar declarações que exigem um bloqueio exclusivo (declarações UPDATE/MERGE/DELETE/DDL) para uma transação diferente, de modo que quaisquer declarações INSERT/COPY possam progredir simultaneamente e as declarações que exijam bloqueios exclusivos possam ser executadas depois delas. Como alternativa, no caso de transações com declarações INSERT/COPY e MERGE/UPDATE/DELETE na mesma tabela, é possível incluir a lógica de repetição em suas aplicações para contornar possíveis deadlocks. # Exemplos de gravações simultâneas Os seguintes exemplos de pseudocódigo demonstram como as transações continuam ou aguardam ao serem executadas simultaneamente. ## Exemplos de gravação simultânea com isolamento serializável ### Operações COPY simultâneas na mesma tabela com isolamento serializável A transação 1 copia linhas na tabela LISTING: ``` begin; copy listing from ...; end; ``` A transação 2 começa simultaneamente em uma sessão separada e tenta copiar mais linhas na tabela LISTING. A transação 2 deve aguardar até que a transação 1 libere o bloqueio de gravação na tabela LISTING para então proceder. ``` begin; [waits] copy listing from ; end; ``` O mesmo comportamento ocorreria se uma ou ambas as transações contivessem um comando INSERT em vez de um comando COPY. ### Operações DELETE simultâneas da mesma tabela com isolamento serializável A transação 1 exclui linhas de uma tabela: ``` begin; delete from listing where ...; end; ``` A transação 2 começa simultaneamente e tenta excluir linhas da mesma tabela. Ela terá êxito, pois ela espera até que a transação 1 seja concluída antes de tentar excluir linhas. ``` begin [waits] delete from listing where ; end; ``` O mesmo comportamento ocorreria se uma ou ambas as transações contivessem um comando UPDATE na mesma tabela em vez de um comando DELETE. ### Transações simultâneas com uma combinação de operações de leitura e de gravação com isolamento serializável Neste exemplo, a transação 1 exclui linhas da tabela USERS, recarrega a tabela, executa uma consulta COUNT(\$1) e ANALYZE antes de confirmar: ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` Enquanto isso, a transação 2 começa. Essa transação tenta copiar linhas adicionais na tabela USERS, analisar a tabela e executar a mesma consulta COUNT (\$1) da primeira transação: ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` A segunda transação terá êxito, pois ela deve aguardar a conclusão da primeira. Sua consulta COUNT retornará a contagem com base no carregamento que foi concluído. ## Exemplos de gravação simultânea com isolamento de snapshot ### Operações COPY simultâneas na mesma tabela com isolamento de snapshot A transação 1 copia linhas na tabela LISTING: ``` begin; copy listing from ...; end; ``` A transação 2 começa simultaneamente em uma sessão separada e tenta copiar mais linhas na tabela LISTING. A Transação 2 pode progredir simultaneamente até que qualquer transação precise gravar dados na tabela de destino `listing`, momento em que as transações serão executadas sequencialmente. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` O mesmo comportamento ocorreria se uma ou ambas as transações contivessem um comando INSERT em vez de um comando COPY. ### Operações DELETE simultâneas da mesma tabela com isolamento de snapshot As operações simultâneas DELETE ou UPDATE da mesma tabela com isolamento de snapshot são executadas da mesma forma que as operações executadas com isolamento serializável. ### Transações simultâneas com uma combinação de operações de leitura e de gravação com isolamento de snapshot As transações simultâneas que são executadas com combinações de operações com isolamento de snapshot são executadas da mesma forma que as transações com combinações de operações executadas com isolamento serializável. # Solucionar problemas de erros de isolamento serializável ## ERROR:1023 DETAIL: Violação de isolamento serializável em uma tabela no Redshift Quando o Amazon Redshift detecta um erro de isolamento serializável, você vê uma mensagem de erro como a seguir. ``` ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift ``` Para resolver um erro de isolamento serializável, você pode tentar um dos seguintes métodos: + Tente executar a transação cancelada novamente. O Amazon Redshift detectou que um workload simultâneo não é serializável. Ele sugere lacunas na lógica da aplicação, que geralmente podem ser contornadas repetindo a transação que encontrou o erro. Se o problema persistir, tente um dos outros métodos. + Mova todas as operações que não precisam estar na mesma transação atômica para fora da transação. Este método é aplicável quando operações individuais em duas transações diferentes fazem referências cruzadas de maneira que possa afetar os resultados. Por exemplo, as duas sessões a seguir iniciam uma transação. ``` Session1_Redshift=# begin; ``` ``` Session2_Redshift=# begin; ``` O resultado de uma instrução SELECT em uma transação pode ser afetado por uma instrução INSERT na outra. Ou seja, suponhamos que você esteja executando as seguintes instruções em série, em qualquer ordem. Em todo caso, o resultado é uma das instruções SELECT retornar uma linha a mais do que ocorreria caso as transações fossem executadas simultaneamente. Não há ordem na qual as operações possam ser executadas em série e ainda obter o mesmo resultado da execução simultânea. Portanto, a última operação executada resulta em um erro de isolamento serializável. ``` Session1_Redshift=# select * from tab1; Session1_Redshift=# insert into tab2 values (1); ``` ``` Session2_Redshift=# insert into tab1 values (1); Session2_Redshift=# select * from tab2; ``` Muitas vezes, o resultado das instruções SELECT não é relevante. Ou seja, a atomicidade das operações nas transações não é importante. Nesses casos, mova as instruções SELECT para fora das transações, conforme mostrado nos exemplos a seguir. ``` 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; ``` Nesses exemplos, não há referências cruzadas nas transações. As duas instruções INSERT não afetam uma à outra. Nesses exemplos, há pelo menos uma ordem na qual as transações podem ser executadas em série e obter o mesmo resultado da execução simultânea. Isso significa que as transações são serializáveis. + Bloqueie todas as tabelas nas sessões para forçar a serialização. O comando [LOCK](r_LOCK.md) bloqueia as operações que podem resultar em erros de isolamento serializado. Ao usar o comando LOCK, faça o seguinte: + Bloqueie todas as tabelas afetadas pela transação, incluindo aquelas afetadas por instruções SELECT somente leitura na transação. + Bloqueie as tabelas na mesma ordem, independentemente da ordem na qual as operações são executadas. + Bloqueie todas as tabelas no início da transação, antes de executar qualquer operação. + Use o isolamento de snapshot para transações simultâneas Use um comando ALTER DATABASE com isolamento de snapshot. Para obter mais informações sobre o parâmetro SNAPSHOT para ALTER DATABASE, consulte [Parâmetros](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters). ## ERROR:1018 DETAIL: A relação não existe Ao executar operações simultâneas do Amazon Redshift em sessões diferentes, uma mensagem de erro semelhante a seguinte é exibida. ``` ERROR: 1018 DETAIL: Relation does not exist. ``` As transações no Amazon Redshift seguem o isolamento de snapshot. Após o início de uma transação, o Amazon Redshift obtém um snapshot do banco de dados. Para todo o ciclo de vida da transação, a transação opera no estado do banco de dados conforme refletido no snapshot. Se a transação lê de uma tabela que não existe no snapshot, ela lança a mensagem de erro 1018 mostrada anteriormente. Mesmo quando outra transação concorrente cria uma tabela após a transação ter obtido o snapshot, a transação não pode ler a partir da tabela recém-criada. Para resolver este erro de isolamento de serialização, você pode tentar mover o início da transação para um ponto onde você sabe que a tabela existe. Se a tabela é criada por outra transação, esse ponto é pelo menos depois que essa transação foi confirmada. Além disso, certifique-se de que nenhuma transação simultânea foi confirmada que possa ter descartado a tabela. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session2 = # BEGIN; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # SELECT * FROM A; ``` A última operação executada como operação de leitura pela sessão2 resulta em um erro de isolamento serializável. Esse erro ocorre quando session2 tira um snapshot e a tabela já foi descartada por uma session1 confirmada. Em outras palavras, mesmo que uma sessão3 simultânea tenha criado a tabela, session2 não vê a tabela porque ela não está no snapshot. Para resolver esse erro, é possível reordenar as sessões da forma a seguir. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # BEGIN; session2 = # SELECT * FROM A; ``` Agora, quando session2 tira seu snapshot, session3 já foi confirmada e a tabela está no banco de dados. Session2 pode ler a partir da tabela sem qualquer erro. # Tutorial: Carregar dados do Amazon S3 Neste tutorial, você percorre o processo de carregamento de dados nas tabelas de banco de dados do Amazon Redshift a partir de arquivos de dados em um bucket do Amazon S3 do início ao fim. Neste tutorial, você faz o seguinte: + Baixa os arquivos de dados que usam formatos separados por vírgulas (CSV), delimitado por caracteres e de largura fixa. + Cria um bucket do Amazon S3 e carrega os arquivos de dados para o bucket. + Inicia um cluster do Amazon Redshift e cria tabelas de banco de dados. + Usa os comandos COPY para carregar as tabelas dos arquivos de dados no Amazon S3. + Soluciona erros de carga e modifica os comandos COPY para corrigir os erros. ## Pré-requisitos Você precisa dos seguintes pré-requisitos: + Uma conta da AWS para iniciar um cluster do Amazon Redshift e criar um bucket no Amazon S3. + Suas credenciais da AWS (função do IAM) para carregar dados de teste do Amazon S3. Se precisar de um novo perfil do IAM, acesse [Criar perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html). + Um cliente SQL, como o editor de consulta do console do Amazon Redshift. Este tutorial foi projetado de maneira que possa ser seguido sozinho. Além deste tutorial, recomendamos concluir os seguintes tutoriais para obter uma compreensão mais completa de como projetar e usar bancos de dados do Amazon Redshift: + O [Guia de conceitos básicos do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) orienta você no processo de criação de um cluster do Amazon Redshift e de carregamento dos dados de exemplo. ## Visão geral Você pode adicionar dados às tabelas do Amazon Redshift usando um comando INSERT ou um comando COPY. Na escala e na velocidade de um data warehouse do Amazon Redshift, o comando COPY é muitas vezes mais rápido e eficiente do que os comandos INSERT. O comando COPY usa a arquitetura de processamento massivamente paralelo (MPP) do Amazon Redshift para ler e carregar dados em paralelo de várias fontes de dados. Você pode carregar arquivos de dados no Amazon S3, Amazon EMR ou qualquer host remoto acessível por meio de uma conexão Secure Shell (SSH). Ou você pode carregar diretamente de uma tabela do Amazon DynamoDB. Neste tutorial, você usa o comando COPY para carregar dados do Amazon S3. Muitos dos princípios apresentados aqui também se aplicam ao carregamento de outras fontes de dados. Para saber mais sobre como usar o comando COPY, consulte estes recursos: + [Práticas recomendadas do Amazon Redshift para carregamento de dados](c_loading-data-best-practices.md) + [Carregar dados do Amazon EMR](loading-data-from-emr.md) + [Carregamento de dados de hosts remotos](loading-data-from-remote-hosts.md) + [Carregar dados de uma tabela do Amazon DynamoDB](t_Loading-data-from-dynamodb.md) ## Etapa 1: criar um cluster Se já tiver um cluster que quiser usar, você poderá ignorar esta etapa. Para os exercícios deste tutorial, você usa um cluster de quatro nós. **Para criar um cluster** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). Usando o menu de navegação, escolha **Painel de clusters provisionados**. **Importante** Verifique se o você tem as permissões necessárias para executar as operações de cluster. Para obter informações sobre como conceder as permissões necessárias, consulte [Autorizar o Amazon Redshift a acessar serviços da AWS](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html). 1. Na parte superior direita, escolha a região da AWS onde você deseja criar o cluster. Para este tutorial, escolha **Oeste dos EUA (Oregon)**. 1. No menu de navegação, escolha **Clusters** e **Create cluster** (Criar cluster). A página **Create cluster (Criar cluster)** é exibida. 1. Na página **Create cluster** (Criar cluster), insira parâmetros do cluster. Escolha seus valores para os parâmetros, sem alterar os seguintes valores: + Escolha **dc2.large** para o tipo de nó. + Escolha **4** em **Number of nodes** (Número de nós). + Na seção **Cluster permissions (Permissões do cluster)**, escolha uma função do IAM em **Available IAM roles (Funções do IAM disponíveis)**. Essa função deve ser uma que você criou anteriormente e que tem acesso ao Amazon S3. Depois, escolha **Associate IAM role** (Associar função do IAM) para adicioná-la à lista de **Associated IAM roles** (Funções do IAM associadas) do cluster. 1. Selecione **Criar cluster**. Siga as etapas do [Guia de conceitos básicos do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) para se conectar de um cliente SQL ao seu cluster e testar uma conexão. Você não precisa concluir as etapas de Conceitos básicos restantes para criar tabelas, fazer upload de dados e testar consultas de exemplo. ## Etapa 2: Fazer download dos arquivos de dados Nesta etapa, você baixará um conjunto de arquivos de dados de exemplo no computador. Na próxima etapa, você carrega os arquivos em um bucket do Amazon S3. **Para baixar os arquivos de dados** 1. Baixe o arquivo compactado: [LoadingDataSampleFiles.zip](samples/LoadingDataSampleFiles.zip). 1. Extraia os arquivos para uma pasta no computador. 1. Verifique se a pasta contém os arquivos a seguir. ``` 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 ``` ## Etapa 3: Carregar arquivos para um bucket do Amazon S3 Nesta etapa, você cria um bucket do Amazon S3 e carrega os arquivos de dados para o bucket. ### **Para carregar arquivos para um bucket do Amazon S3** 1. Crie um bucket no Amazon S3. Para obter mais informações sobre como criar um bucket, consulte [Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html), no *Guia do usuário do Amazon Simple Storage Service*. 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Escolha **Criar bucket**. 1. Escolha um Região da AWS. Crie o bucket na mesma região do cluster. Se o cluster estiver na região Oeste dos EUA (Oregon), escolha **US West (Oregon) Region (us-west-2)**. 1. Na caixa **Nome do bucket** da caixa de diálogo **Criar um bucket**, digite o nome de um bucket. O nome de bucket que você escolher deve ser único entre todos os nomes de bucket existentes no Amazon S3. Uma forma de ajudar a garantir a exclusividade é prefixar seus nomes de bucket com o nome de sua organização. Os nomes de bucket devem estar em conformidade com determinadas regras. Para obter mais informações, acesse [Restrições e limitações de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) no *Guia do usuário do Amazon Simple Storage Service*. 1. Escolha os padrões recomendados para o restante das opções. 1. Escolha **Criar bucket**. Quando o Amazon S3 cria seu bucket com sucesso, o console exibe seu bucket vazio no painel **Buckets**. 1. Crie uma pasta. 1. Escolha o nome do novo bucket. 1. Selecione o botão **Criar pasta**. 1. Nomeie a nova pasta como **load**. **nota** O bucket que você criou não está em um sandbox. Neste exercício, você adiciona objetos a um bucket real. Um valor nominal é cobrado pelo tempo em que você armazena os objetos no bucket. Para obter mais informações sobre preços do Amazon S3, consulte [Preço do Amazon S3](https://aws.amazon.com/s3/pricing/). 1. Carregue arquivos de dados para o novo bucket do Amazon S3. 1. Escolha o nome da pasta de dados. 1. No assistente de upload, escolha **Adicionar arquivos**. Siga as instruções do console do Amazon S3 para carregar todos os arquivos que você baixou e extraiu. 1. Escolha **Carregar**. **Credenciais do usuário** O comando COPY do Amazon Redshift deve ter acesso para ler os objetos de arquivo no bucket do Amazon S3. Se você usar as mesmas credenciais de usuário para criar o bucket do Amazon S3 e para executar o comando COPY do Amazon Redshift, o comando COPY tem todas as permissões necessárias. Se quiser usar credenciais de usuário diferentes, você pode conceder acesso usando os controles de acesso do Amazon S3. O comando COPY do Amazon Redshift requer pelo menos as permissões ListBucket e GetObject para acessar os objetos de arquivo no bucket do Amazon S3. Para obter mais informações sobre como controlar o acesso aos recursos do Amazon S3, consulte [Gerenciar permissões de acesso aos recursos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). ## Etapa 4: Criar as tabelas de exemplo Neste tutorial, você usará um conjunto de tabelas baseadas no esquema Star Schema Benchmark (SSB). O diagrama a seguir mostra o modelo de dados SSB. ![\[As cinco tabelas do esquema SSB e suas inter-relações.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/tutorial-optimize-tables-ssb-data-model.png) As tabelas SSB talvez já existam no banco de dados atual. Nesse caso, descarte as tabelas para removê-las do banco de dados antes de criá-las usando os comandos CREATE TABLE na próxima etapa. As tabelas usadas neste tutorial podem ter atributos diferentes das tabelas existentes. **Para criar as tabelas de exemplo** 1. Para remover tabelas SSB, execute os comandos a seguir no cliente SQL. ``` drop table part cascade; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` 1. Execute os comandos CREATE TABLE a seguir em seu cliente 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 ); ``` ## Etapa 5: Executar os comandos COPY Você executa os comandos COPY para carregar cada uma das tabelas no esquema SSB. Os exemplos de comando COPY demonstram como carregar de formatos de arquivo diferentes usando várias opções de comando COPY e solucionando erros de carga. ### Sintaxe do comando COPY A seguir, a sintaxe básica do comando [COPY](r_COPY.md). ``` COPY table_name [ column_list ] FROM data_source CREDENTIALS access_credentials [options] ``` Para executar um comando COPY, forneça os valores a seguir. **Nome da tabela** A tabela de destino do comando COPY. A tabela já deve existir no banco de dados. A tabela pode ser temporária ou persistente. O comando COPY acrescenta os novos dados de entrada a todas as linhas existentes na tabela. **Lista de colunas** Por padrão, COPY carrega campos dos dados de origem para as colunas da tabela na ordem. Você pode especificar uma *lista de colunas*, uma lista separada por vírgulas de nomes de coluna, a fim de mapear campos de dados para colunas específicas. Você não usa listas de colunas neste tutorial. Para obter mais informações, consulte [Column List](copy-parameters-column-mapping.md#copy-column-list) na referência do comando COPY. Fonte de dados Você pode usar o comando COPY para carregar dados de um bucket do Amazon S3, um cluster do Amazon EMR, um host remoto usando uma conexão SSH ou uma tabela do Amazon DynamoDB. Para este tutorial, você carrega de arquivos de dados em um bucket do Amazon S3. Ao carregar do Amazon S3, você deve fornecer o nome do bucket e a localização dos arquivos de dados. Para fazer isso, forneça o caminho de um objeto para os arquivos de dados ou a localização de um arquivo manifesto que lista explicitamente cada arquivo de dados e sua localização. + Prefixo de chaves Um objeto armazenado no Amazon S3 é identificado exclusivamente por uma chave de objeto, que inclui o nome do bucket, os nomes das pastas, se houver, e o nome do objeto. Um *prefixo de chaves *se refere a um conjunto de objetos com o mesmo prefixo. O caminho do objeto é um prefixo de chaves usado pelo comando COPY para carregar todos os objetos que compartilham o prefixo de chaves. Por exemplo, o prefixo de chaves `custdata.txt` pode referenciar um único arquivo ou um conjunto de arquivos, inclusive `custdata.txt.001``custdata.txt.002` e assim por diante. + Arquivo manifesto Em alguns casos, pode ser necessário carregar os arquivos com prefixos diferentes, por exemplo, de vários buckets ou pastas. Em outros, pode ser necessário excluir arquivos que compartilham um prefixo. Nesses casos, é possível usar um arquivo manifesto. Um *arquivo manifesto* lista cada arquivo de carga e a chave de objeto exclusiva. Você usa um arquivo manifesto para carregar a tabela PART posteriormente neste tutorial. **Credenciais** Para acessar os recursos da AWS que contêm os dados a serem carregados, você deve fornecer as credenciais de acesso da AWS a um usuário com privilégios suficientes. Essas credenciais incluem um nome do recurso da Amazon (ARN) da função do IAM. Para carregar dados do Amazon S3, as credenciais devem incluir as permissões ListBucket e GetObject. Serão necessárias outras credenciais, se os dados estiverem criptografados. Para obter mais informações, consulte [Parâmetros de autorização](copy-parameters-authorization.md) na referência do comando COPY. Para obter mais informações sobre como gerenciar o acesso, consulte [Gerenciar permissões de acesso aos seus recursos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). Opções Você pode especificar vários parâmetros com o comando COPY para especificar formatos de arquivo, gerenciar formatos de dados, gerenciar erros e controlar outros recursos. Neste tutorial, você usa as seguintes opções e os seguintes recursos do comando COPY: + Prefixo de chaves Para obter informações sobre como carregar de vários arquivos especificando um prefixo de chave, consulte [Carregar a tabela PART usando NULL AS](#tutorial-loading-load-part). + Formato CSV Para obter informações sobre como carregar dados que estão no formato CSV, consulte [Carregar a tabela PART usando NULL AS](#tutorial-loading-load-part). + NULL AS Para obter informações sobre como carregar PART usando a opção NULL AS, consulte [Carregar a tabela PART usando NULL AS](#tutorial-loading-load-part). + Formato delimitado por caracteres Para obter informações sobre como usar a opção DELIMITER, consulte [As opções DELIMITER e REGION](#tutorial-loading-load-supplier). + REGION Para obter informações sobre como usar a opção REGION, consulte [As opções DELIMITER e REGION](#tutorial-loading-load-supplier). + Largura de formato fixo Para obter informações sobre como carregar a tabela CUSTOMER de dados de largura fixa, consulte [Carregar a tabela CUSTOMER usando MANIFEST](#tutorial-loading-load-customer). + MAXERROR Para obter informações sobre como usar a opção MAXERROR, consulte [Carregar a tabela CUSTOMER usando MANIFEST](#tutorial-loading-load-customer). + ACCEPTINVCHARS Para obter informações sobre como usar a opção ACCEPTINVCHARS, consulte [Carregar a tabela CUSTOMER usando MANIFEST](#tutorial-loading-load-customer). + MANIFEST Para obter informações sobre como usar a opção MANIFEST, consulte [Carregar a tabela CUSTOMER usando MANIFEST](#tutorial-loading-load-customer). + DATEFORMAT Para obter informações sobre como usar a opção DATEFORMAT, consulte [Carregar a tabela DWDATE usando DATEFORMAT](#tutorial-loading-load-dwdate). + GZIP, LZOP e BZIP2 Para obter informações sobre como compactar arquivos, consulte [Carregar vários arquivos de dados](#tutorial-loading-load-lineorder). + COMPUPDATE Para obter informações sobre como usar a opção COMPUPDATE, consulte [Carregar vários arquivos de dados](#tutorial-loading-load-lineorder). + Vários arquivos Para obter informações sobre como carregar vários arquivos, consulte [Carregar vários arquivos de dados](#tutorial-loading-load-lineorder). ### Carregar as tabelas SSB Você usa os comandos COPY a seguir para carregar cada uma das tabelas no esquema SSB. O comando para cada tabela demonstra opções de COPY e técnicas para solução de problemas diferentes. Para carregar as tabelas SSB, siga estas etapas: 1. [Substituir o nome do bucket e as credenciais da AWS](#tutorial-loading-run-copy-replaceables) 1. [Carregar a tabela PART usando NULL AS](#tutorial-loading-load-part) 1. [Carregar a tabela CUSTOMER usando MANIFEST](#tutorial-loading-load-customer) 1. [Carregar a tabela DWDATE usando DATEFORMAT](#tutorial-loading-load-dwdate) #### Substituir o nome do bucket e as credenciais da AWS Os comandos COPY neste tutorial são apresentados no formato a seguir. ``` copy table from 's3:///load/key_prefix' credentials 'aws_iam_role=arn:aws:iam:::role/' options; ``` Para cada comando COPY, faça o seguinte: 1. Substitua ** pelo nome de um bucket na mesma região do cluster. Essa etapa pressupõe que o bucket e o cluster estejam na mesma região. Você também pode especificar a região usando a opção [REGION](copy-parameters-data-source-s3.md#copy-region) com o comando COPY. 1. Substitua ** e ** por sua Conta da AWS e função do IAM. O segmento da string de credenciais entre aspas não deve conter espaços ou quebras de linha. O formato do ARN pode ser levemente diferente do formato da amostra. Ao executar os comandos COPY, é melhor copiar o ARN do perfil pelo console do IAM, para garantir que ele seja preciso. #### Carregar a tabela PART usando NULL AS Nesta etapa, você usa as opções CSV e NULL AS para carregar a tabela PART. O comando COPY pode carregar dados de vários arquivos em paralelo, o que é muito mais rápido do que carregar de um único arquivo. Para demonstrar esse princípio, os dados de cada tabela neste tutorial estão divididos em oito arquivos, mesmo que os arquivos sejam muito pequenos. Em uma etapa posterior, você compara a diferença de tempo entre o carregamento de um único arquivo e carregar de vários arquivos. Para obter mais informações, consulte [Carregar arquivos de dados](c_best-practices-use-multiple-files.md). **Prefixo de chaves** Você pode carregar de vários arquivos especificando um prefixo de chaves para o conjunto de arquivos ou listando explicitamente os arquivos em um arquivo manifesto. Nesta etapa, você usa um prefixo de chaves. Em uma etapa posterior, você usa um arquivo manifesto. O prefixo de chaves `'s3://amzn-s3-demo-bucket/load/part-csv.tbl'` carrega o conjunto de arquivos a seguir na pasta `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, que significa comma separated values, ou valores separados por vírgulas, é um formato comum usado para importar e exportar dados da planilha. CSV é mais flexível do que o formato delimitado por vírgulas porque permite incluir strings de aspas dentro dos campos. O caractere de aspa padrão para o formato COPY from CSV é uma aspa dupla ("), mas você pode especificar outro caractere de aspa usando a opção QUOTE AS. Ao usar aspas dentro do campo, escape o caractere com aspas adicionais. O seguinte trecho de um arquivo de dados formatado em CSV para a tabela PART mostra strings entre aspas duplas (`"LARGE ANODIZED BRASS"`). Ele também mostra uma string entre aspas duplas dentro da string entre aspas (`"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 ``` Os dados da tabela PART contêm caracteres que causam uma falha no comando COPY. Neste exercício, você soluciona problemas e corrige-os. Para carregar dados que estejam em formato CSV, adicione `csv` ao comando COPY. Execute o comando a seguir para carregar a tabela PART. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv; ``` Você poderá receber uma mensagem de erro semelhante à mensagem a seguir. ``` 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. ``` Para obter mais informações sobre o erro, consulte a tabela STL\$1LOAD\$1ERRORS. A consulta a seguir usar a função SUBSTRING para encurtar colunas para fins de legibilidade e usa LIMIT 10 para reduzir o número de linhas retornadas. Você pode ajustar os valores em `substring(filename,22,25)` para permitir o comprimento do nome do 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** Os arquivos de dados `part-csv.tbl` usam o caractere terminador NUL (`\x000` ou `\x0`) para indicar valores NULL. **nota** Apesar da ortografia muito semelhante, NUL e NULL não são iguais. NUL é um caractere UTF-8 com codepoint `x000` normalmente usado para indicar End Of Record (EOR – Fim do registro). NULL é um valor SQL que representa uma ausência de dados. Por padrão, COPY trata um caractere terminador NUL como um caractere EOR e encerra o registro, o que normalmente acarreta em resultados inesperados ou em um erro. Não existe um único método padrão para indicar NULL em dados de texto. Assim, a opção do comando NULL AS COPY permite especificar qual caractere substituir por NULL ao carregar a tabela. Neste exemplo, você deseja que COPY trate o caractere terminador NUL como um valor NULL. **nota** A coluna da tabela que recebe o valor NULL deve ser configurada como *anulável.* Ou seja, ela não deve incluir a restrição NOT NULL na especificação CREATE TABLE. Para carregar PART usando a opção NULL AS, execute o comando COPY a seguir. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv null as '\000'; ``` Para verificar se o COPY carregou valores NULL, execute o comando a seguir para selecionar somente as linhas que contenham 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) ``` #### As opções DELIMITER e REGION As opções DELIMITER e REGION são importantes para entender como carregar os dados. **Formato delimitado por caracteres** Os campos em um arquivo delimitado por caracteres são separados por um caractere específico, como uma barra ( \$1 ), uma vírgula ( , ) ou uma tabulação ( \$1t ). Os arquivos delimitados por caractere podem usar qualquer caractere ASCII único, inclusive um dos caracteres ASCII não imprimíveis, como o delimitador. Você especifica o caractere delimitador usando a opção DELIMITER. O delimitador padrão é um caractere de barra ( \$1 ). O trecho a seguir dos dados da tabela SUPPLIER usa o formato delimitado por barras. ``` 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** Sempre que possível, você deve localizar seus dados de carga na mesma região da AWS do cluster do Amazon Redshift. Se seus dados e cluster estiverem na mesma região, você reduz a latência e evita custos de transferência de dados entre regiões. Para obter mais informações, consulte [Práticas recomendadas do Amazon Redshift para carregamento de dados](c_loading-data-best-practices.md). Se você precisar carregar dados de uma região da AWS diferente, use a opção REGION para especificar a região da AWS na qual os dados de carga estão localizados. Se você especificar uma região, todos os dados da carga, inclusive arquivos manifestos, deverão estar na região nomeada. Para obter mais informações, consulte [REGION](copy-parameters-data-source-s3.md#copy-region). Por exemplo, se o cluster estiver na região Leste dos EUA (Norte da Virgínia) e o bucket do Amazon S3 estiver na região Oeste dos EUA (Oregon), o comando COPY a seguir mostrará como carregar a tabela SUPPLIER usando dados delimitados por pipe. ``` 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'; ``` #### Carregar a tabela CUSTOMER usando MANIFEST Nesta etapa, você usa as opções FIXEDWIDTH, MAXERROR, ACCEPTINVCHARS e MANIFEST para carregar a tabela CUSTOMER. Os dados de exemplo deste exercício contêm caracteres que causam erros quando COPY tenta carregá-los. Você usa a opção MAXERRORS e a tabela do sistema STL\$1LOAD\$1ERRORS para solucionar erros de carga e usa as opções ACCEPTINVCHARS e MANIFEST para eliminar os erros. **Formato de largura fixa** O formato de largura fixa define cada campo como um número de caracteres fixo, em vez de separar campos com um delimitador. O trecho a seguir dos dados da tabela CUSTOMER usa o formato de largura fixa. ``` 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 ``` A ordem dos pares de rótulo/largura deve corresponder exatamente à ordem das colunas da tabela. Para obter mais informações, consulte [FIXEDWIDTH](copy-parameters-data-format.md#copy-fixedwidth). A seguir, a string de especificação de largura fixa dos dados da tabela CUSTOMER. ``` 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' ``` Para carregar a tabela CUSTOMER de dados de largura fixa, execute o comando a seguir. ``` 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'; ``` Você deve receber uma mensagem de erro, semelhante à mensagem a seguir. ``` 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** Por padrão, a primeira vez em que COPY encontra um erro, o comando falha e retorna uma mensagem de erro. Para economizar tempo durante testes, você pode usar a opção MAXERROR para instruir COPY a ignorar um número especificado de erros antes de falhar. Como esperamos erros na primeira vez em que testamos o carregamento dos dados da tabela CUSTOMER, adicionamos `maxerror 10` ao comando COPY. Para testar usando as opções FIXEDWIDTH e MAXERROR, execute o comando a seguir. ``` 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; ``` Desta vez, em vez de uma mensagem de erro, você recebe uma mensagem de aviso semelhante à que se segue. ``` 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. ``` O aviso indica que COPY encontrou sete erros. Para verificar erros, consulte a tabela STL\$1LOAD\$1ERRORS, conforme mostrado no exemplo a seguir. ``` 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; ``` Os resultados da consulta STL\$1LOAD\$1ERRORS devem ser semelhantes aos resultados a seguir. ``` 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) ``` Examinando os resultados, você pode ver que existem duas mensagens na coluna `error_reasons`: + ``` Invalid digit, Value '#', Pos 0, Type: Integ ``` Esses erros são causados pelo arquivo `customer-fw.tbl.log`. O problema é que se trata de um arquivo de log, não um arquivo de dados, e não deve ser carregado. Você pode usar um arquivo manifesto para evitar carregar o arquivo errado. + ``` String contains invalid or unsupported UTF8 ``` O tipo de dados VARCHAR dá suporte a caracteres UTF-8 multibyte até três bytes. Se os dados de carga contiverem caracteres incompatíveis ou inválidos, você poderá usar a opção ACCEPTINVCHARS para substituir cada caractere inválido por um caractere alternativo especificado. Outro problema com a carga é mais difícil de detectar — a carga produziu resultados inesperados. Para investigar esse problema, execute o comando a seguir para consultar a tabela CUSTOMER. ``` 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) ``` As linhas devem ser exclusivas, mas há duplicações. Outra maneira de verificar se há resultados inesperados é consultar o número de linhas que foram carregadas. Em nosso caso, 100.000 linhas devem ter sido carregadas, mas a mensagem de carga relatou o carregamento de 112.497. As linhas extra foram carregadas porque COPY carregou um arquivo estranho, `customer-fw.tbl0000.bak`. Neste exercício, você usa um arquivo manifesto para evitar carregar os arquivos errados. **ACCEPTINVCHARS** Por padrão, quando encontra um caractere que não seja compatível com o tipo de dados da coluna, COPY ignora a linha retorna um erro. Para obter informações sobre caracteres UTF-8 inválidos, consulte [Erros no carregamento de caracteres multibyte](multi-byte-character-load-errors.md). Você pode usar a opção MAXERRORS para ignorar erros e continuar carregando, a consulta STL\$1LOAD\$1ERRORS para localizar os caracteres inválidos e corrigir os arquivos de dados. Porém, MAXERRORS é mais bem usado na solução de problemas de carga e normalmente não deve ser usado em um ambiente de produção. A opção ACCEPTINVCHARS normalmente é uma opção melhor para gerenciar caracteres inválidos. ACCEPTINVCHARS orienta COPY a substituir cada caractere inválido por um caractere válido especificado e continuar a operação de carga. Você pode especificar qualquer caractere ASCII válido, exceto NULL, como o caractere substituto. O caractere de substituição padrão é um ponto de interrogação (? ). COPY substitui caracteres multibyte por uma string de substituição de comprimento igual. Por exemplo, um caractere de 4 bytes seria substituído por `'????'`. COPY retorna o número de linhas que continham caracteres UTF-8 errados. Ele também adiciona uma entrada à tabela STL\$1REPLACEMENTS para cada linha afetada, até um máximo de 100 linhas por fatia de nó. Os caracteres UTF-8 inválidos adicionais também são substituídos, mas esses eventos substitutos não são registrados. ACCEPTINVCHARS só é válido para colunas VARCHAR. Para esta etapa, você adiciona o ACCEPTINVCHARS com o caractere de substituição `'^'`. **MANIFEST** Quando você COPY do Amazon S3 usando um prefixo das chave, há o risco de carregar tabelas indesejadas. Por exemplo, a pasta `'s3://amzn-s3-demo-bucket/load/` contém oito arquivos de dados que compartilham o prefixo de chaves `customer-fw.tbl`: `customer-fw.tbl0000`, `customer-fw.tbl0001` e assim por diante. Porém, a mesma pasta também contém arquivos estranhos `customer-fw.tbl.log` e `customer-fw.tbl-0001.bak`. Para garantir que você carregue todos os arquivos corretos, e somente os corretos, use um arquivo manifesto. Manifesto é um arquivo de texto em formato JSON que lista explicitamente a chave de objeto exclusiva para cada arquivo de origem a ser carregado. Os objetos de arquivo podem estar em pastas ou em buckets diferentes, mas devem estar na mesma região. Para obter mais informações, consulte [MANIFEST](copy-parameters-data-source-s3.md#copy-manifest). A seguir, o texto `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"} ] } ``` **Para carregar os dados da tabela CUSTOMER usando o arquivo manifesto** 1. Abra o arquivo `customer-fw-manifest` em um editor de texto. 1. Substitua ** pelo nome do seu bucket. 1. Salve o arquivo. 1. Faça upload do arquivo na pasta de carga do bucket. 1. Execute o comando COPY a seguir. ``` 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; ``` #### Carregar a tabela DWDATE usando DATEFORMAT Nesta etapa, você usa as opções DELIMITER e DATEFORMAT para carregar a tabela DWDATE. Ao carregar as colunas DATE e TIMESTAMP, COPY espera o formato padrão, que é AAAA-MM-DD para datas e AAAA-MM-DD HH:MI SS para timestamps. Se os dados de carga não usarem um formato padrão, você poderá usar DATEFORMAT e TIMEFORMAT para especificar o formato. O trecho a seguir mostra formatos de data na tabela DWDATE. Observe que os formatos de data na coluna dois são inconsistentes. ``` 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** Você pode especificar somente um formato de data. Se os dados de carga contiverem formatos inconsistentes, possivelmente em colunas diferentes, ou se o formato não for conhecido no tempo de carregamento, você usará DATEFORMAT com o argumento `'auto'`. Quando `'auto'` for especificado, COPY reconhece qualquer formato de data ou hora válido e o converterá no formato padrão. A opção `'auto'` reconhece diversos formatos não compatíveis ao usar uma string DATEFORMAT e TIMEFORMAT. Para obter mais informações, consulte [Usar o reconhecimento automático com DATEFORMAT e TIMEFORMAT](automatic-recognition.md). Para carregar a tabela DWDATE, execute o comando COPY a seguir. ``` copy dwdate from 's3:///load/dwdate-tab.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' delimiter '\t' dateformat 'auto'; ``` #### Carregar vários arquivos de dados Você pode usar as opções GZIP e COMPUPDATE para carregar uma tabela. Você pode carregar uma tabela usando um único arquivo de dados ou vários arquivos. Isso permite comparar os tempos de carregamento dos dois métodos. **GZIP, LZOP e BZIP2** Você pode compactar os arquivos usando os formatos de compactação gzip, lzop ou bzip2. Ao carregar de arquivos compactados, COPY descompacta os arquivos durante o processo de carga. Compactar os arquivos economiza espaço de armazenamento e encurta tempos de upload. **COMPUPDATE** Quando carrega uma tabela vazia sem codificações de compactação, COPY analisa os dados de carga para determinar as codificações ideais. Em seguida, ele altera a tabela para usar essas codificações antes de iniciar a carga. Esse processo de análise demora, mas ocorre, no máximo, uma vez por tabela. Para economizar tempo, você pode ignorar esta etapa desativando COMPUPDATE. Para permitir uma avaliação precisa dos tempos de COPY, você desativa COMPUPDATE para esta etapa. **Vários arquivos** O comando COPY pode carregar dados de maneira muito eficiente ao carregar de vários arquivos em paralelo, em vez de carregar de um único arquivo. É possível dividir seus dados em arquivos de modo que o número de arquivos seja um múltiplo do número de fatias em seu cluster. Se você fizer isso, o Amazon Redshift dividirá o workload e distribuirá os dados uniformemente entre as fatias. O número de fatias por nó depende do tamanho do nó do cluster. Para obter mais informações sobre o número de fatias que cada tamanho de nó possui, consulte “[Clusters e nós no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes)” no *Guia de gerenciamento de clusters do Amazon Redshift*. Por exemplo, neste tutorial, os nós de computação no cluster podem ter duas fatias cada; portanto, um cluster com quatro nós tem oito fatias. Em etapas anteriores, os dados da carga estavam contidos em oito arquivos, mesmo que os arquivos fossem muito pequenos. Nesta etapa, você compara a diferença de tempo entre o carregamento de um único arquivo grande e o carregamento de vários arquivos. Até mesmo arquivos que contêm 15 milhões de registros e ocupam 1,2 GB são muito pequenos na escala do Amazon Redshift. Mas eles são suficientes para demonstrar a vantagem em termos de performance de carregar de vários arquivos. A imagem a seguir mostra os arquivos de dados para a tabela LINEORDER. ![\[Os dados na tabela LINEORDER dividem-se em nove arquivos.\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/images/tutorial-load-lineorder-files.png) **Para avaliar a performance de COPY com vários arquivos** 1. Em um teste de laboratório, o comando a seguir foi executado para fazer o COPY usando um único arquivo. Este comando mostra um bucket fictício. ``` 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. Os resultados são mostrados a seguir. Observe o tempo de execução. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 51.56s ``` 1. Em seguida, o comando abaixo foi executado para fazer o COPY usando vários arquivos. ``` 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. Os resultados são mostrados a seguir. Observe o tempo de execução. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 17.7s ``` 1. Compare tempos de execução. No nosso experimento, o tempo para carregar 15 milhões de registros diminuiu de 51,56 segundos para 17,7 segundos, uma redução de 65,7%. Esses resultados se baseiam no uso de um cluster de quatro nós. Se o cluster tiver mais nós, o tempo economizado será multiplicado. Para clusters típicos do Amazon Redshift, com dezenas a centenas de nós, a diferença é ainda mais dramática. Se você tiver um único cluster de nó, haverá pouca diferença entre os tempos de execução. ## Etapa 6: Vacuum e análise do banco de dados Sempre que adicionar, excluir ou modificar um número significativo de linhas, você deve executar um comando VACUUM e depois um comando ANALYZE. Uma *limpeza* recupera o espaço de linhas excluídas e restaura a ordem de classificação. O comando ANALYZE atualiza os metadados de estatísticas, o que permite ao otimizador de consultas gerar planos de consulta mais precisos. Para obter mais informações, consulte [Vacuum de tabelas](t_Reclaiming_storage_space202.md). Se você carregar os dados na ordem da chave de classificação, a limpeza será rápida. Neste tutorial, você adicionou um número significativo de linhas, mas as adicionou a tabelas vazias. Sendo esse o caso, não há necessidade de corrigir, e você não excluiu linhas. COPY atualizará automaticamente estatísticas de atualizações depois de carregar uma tabela vazia, logo, as estatísticas devem permanecer atualizadas. Porém, por uma questão de boas práticas de manutenção, você conclui este tutorial limpando e analisando o banco de dados. Para limpar e analisar o banco de dados, execute os comandos a seguir. ``` vacuum; analyze; ``` ## Etapa 7: limpar os recursos O cluster continua acumulando cobranças enquanto está em execução. Ao concluir este tutorial, você deve retornar seu ambiente ao estado anterior seguindo as etapas na [Etapa 5: Revogar o acesso e excluir sua amostra de cluster](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) no *Guia de conceitos básicos do Amazon Redshift*. Caso queira manter o cluster, mas recuperar o armazenamento usado pelas tabelas SSB, execute os comandos a seguir. ``` drop table part; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` ### Próximo [Resumo](#tutorial-loading-data-summary) ## Resumo Neste tutorial, você carregou arquivos de dados no Amazon S3 e, em seguida, usou os comandos COPY para carregar os dados dos arquivos nas tabelas do Amazon Redshift. Você carregou dados usando os seguintes formatos: + Delimitado por caracteres + CSV + Largura fixa Você usou a tabela do sistema STL\$1LOAD\$1ERRORS para solucionar erros de carga e usou as opções REGION, MANIFEST, MAXERROR, ACCEPTINVCHARS, DATEFORMAT e NULL AS para resolver os erros. Você aplicou estas melhores práticas para carregar dados: + [Uso de um comando COPY para carregar dados](c_best-practices-use-copy.md) + [Carregar arquivos de dados](c_best-practices-use-multiple-files.md) + [Uso de um único comando COPY para carregar a partir de vários arquivos](c_best-practices-single-copy-command.md) + [Compactar arquivos de dados](c_best-practices-compress-data-files.md) + [Verificação de arquivos de dados antes de depois de um carregamento](c_best-practices-verifying-data-files.md) Para obter mais informações sobre as práticas recomendadas do Amazon Redshift, consulte os seguintes links: + [Práticas recomendadas do Amazon Redshift para carregamento de dados](c_loading-data-best-practices.md) + [Práticas recomendadas do Amazon Redshift para projetar tabelas](c_designing-tables-best-practices.md) + [Práticas recomendadas do Amazon Redshift para criar consultas](c_designing-queries-best-practices.md)