Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.

Visão geral de serviço
- O que é o GaussDB(DWS)?
- Tipos de Data Warehouse
- Especificações do armazém de dados
- Vantagens
- Cenários de aplicação
- Funções
- Conceitos
- Serviços relacionados
- Gerenciamento de permissões do GaussDB(DWS)
- Acesso ao GaussDB(DWS)
- Detalhes de preços
- Restrições
- Service Quotas
- Especificações técnicas
- Descrição da versão
Guia de gerenciamento
- Processo para usar o GaussDB(DWS)
- Preparativos
- Criação ou exclusão de um cluster
- Conexão de clusters
- Monitoramento e alarmes
- Mudança e dimensionamento de especificações
- Backup e recuperação de desastres
  - Snapshots
  - DR do cluster
- O&M inteligente
- Gerenciamento de cluster
- Migração de dados
- Gerenciamento de logs de cluster
- Gerenciamento de usuários de banco de dados
  - Gerenciamento de usuários
  - Gerenciamento de funções
- Logs de auditoria
- Gerenciamento de segurança de cluster
- Gerenciamento de recursos
- Gerenciamento de fonte de dados
  - Fontes de dados do MRS
  - Gerenciamento de fontes de dados do OBS
- Gerenciamento de clusters lógicos
Referência de API
- Antes de começar
- Visão geral de API
- Chamada das API
- Introdução
- Descrição de API
  - As API de gerenciamento de cluster
  - As API de gerenciamento de snapshot
- Casos de aplicação
  - Uso de Postman para chamar a API para criar um snapshot
- Políticas de permissões e ações suportadas
- Apêndice
Primeiros passos
- Passo 1: Preparação antes da entrada
- Passo 2: criação de um cluster
- Passo 3: conexão a um cluster
- Passo 4: Exibindo Outros Documentos e Compensando Recursos
Perguntas frequentes
- Perguntas frequentes principais
- Problemas gerais
- Uso do banco de dados
- Gerenciamento de clusters
- Conexões de banco de dados
- Importação e exportação de dados
- Conta, senha e permissão
- Desempenho do banco de dados
- Backup e restauração do snapshot
  1. Por que criar um snapshot automatizado é tão lento?
  2. Um snapshot de DWS tem a mesma função que um snapshot de EVS?
- Cobrança
Melhores práticas
- Importação e exportação
- Migração de dados
- Práticas da otimização de tabela
- Recursos avançados
- Gerenciamento de banco de dados
- Análise de dados de amostra
- Gerenciamento de segurança
No momento, o conteúdo não está disponível no seu idioma selecionado. Consulte a versão em inglês.
What's New
Function Overview
Product Bulletin
- Product Notice
- Version Support Notes
Billing
- GaussDB(DWS) Billing Overview
- Billing Modes
- Item
- Billing Examples
- Billing Mode Change
- Renewal
  - Overview
  - Manual Renewal
- Bills
- Arrears
- Stopping Billing
- Cost Management
- Billing FAQs
Data Migration and Synchronization
- Data Migration to GaussDB(DWS)
- Importing Data
- Full Database Migration
  - Using CDM to Migrate Data to GaussDB(DWS)
  - Using DSC to Migrate SQL Scripts
- Real-time Import
  - Using DRS to Import Data to GaussDB(DWS)
  - Real-time Data Import From Kafka GaussDB(DWS)
- Metadata Migration
  - Using gs_dump and gs_dumpall to Export Metadata
  - Using gs_restore to Import Data
- Exporting Data
- Other Operations
Developer Guide
- Standard data warehouse (9.1.0.x)
- Standard data warehouse (8.1.3.x)
- Hybrid Data Warehouse (9.1.0.x）
- Hybrid Data Warehouse (8.1.3.x）
- Historical Versions
SQL Syntax Reference
- SQL Syntax Reference (9.1.0.x)
- SQL Syntax Reference (8.1.3.x)
- Historical Versions
Performance Tuning
- Overview of Query Performance Optimization
- Query Execution Process
- SQL Execution Plan
- SQL Optimization Guide
- Optimization Cases
- SQL Execution Troubleshooting
- query_band Load Identification
- Common Performance Parameter Optimization Design
Tool Guide
- Overview
- Downloading Related Tools
- gsql
- Data Studio
- GDS
- DSC
- DataCheck
- DWS-Connector
- Server Tool
SDK Reference
- SDK Overview
Troubleshooting
- Database Connections
- JDBC/ODBC
- Data Import and Export
- Database Parameter Modification
- Account/Permission/Password
- Cluster Performance
- Cluster Exceptions
  - The Disk Usage Alarm Is Frequently Generated
- Database Use
Videos
Performance White Paper
- Overview
- Test Result
  - TPC-H Single Query Test
  - TPC-DS Single Query Test
- Test Methods
- Appendixes
  - TPC-H Test Sets
  - TPC-DS Test Sets
Technical White Paper
- GaussDB(DWS)
- Platforms and Technical Specifications Supported by GaussDB(DWS)
  - Technical Specifications
- GaussDB(DWS) Core Technologies
- GaussDB(DWS) Tools
  - Client Tools
  - Database Monitoring Tool
- External APIs
Error Code Reference
- 8.2.0 and earlier versions
  - Management Console Error Code
  - Data Warehouse Service Error Codes
- 8.2.1 or later versions
Glossary
More Documents
- User Guide
- API Reference (ME-Abu Dhabi Region)
- Developer Guide (ME-Abu Dhabi Region)
- SQL Syntax Reference (ME-Abu Dhabi Region)
- Tool Guide (ME-Abu Dhabi Region)
- Error Code Reference (ME-Abu Dhabi Region)
  - Management Console Error Code
- User Guide (Paris Region)
- API Reference (Paris Region)
- Developer Guide (Paris Region)
- SQL Syntax Reference (Paris Region)
- Tool Guide (Paris Region)
- Error Code Reference (Paris Region)
  - Management Console Error Code
- User Guide (Kuala Lumpur Region)
- API Reference (Kuala Lumpur Region)
- Developer Guide (Kuala Lumpur Region)
- SQL Syntax Reference (Kuala Lumpur Region)
- Tool Guide (Kuala Lumpur Region)
- Error Code Reference (Kuala Lumpur Region)
  - Management Console Error Code

Nesta página

Os resultados da função de janela são classificados incompletamente
Usar a classificação em subvisões/subconsultas
LIMIT em subconsultas
Usar String_agg
Modo de compatibilidade de banco de dados
O item de configuração behavior_compat_options para comportamentos de compatibilidade de banco de dados é configurado de forma inconsistente.
Os atributos da função definida pelo usuário não estão configurados corretamente.
Usar a tabela não registrada

Mostrar todos

Central de ajuda/ GaussDB(DWS)/ Perguntas frequentes/ Uso do banco de dados/ Soluções para resultados de consultas inconsistentes do GaussDB(DWS)

Soluções para resultados de consultas inconsistentes do GaussDB(DWS)

Atualizado em 2025-01-23 GMT+08:00

Ver PDF

No GaussDB(DWS), às vezes uma consulta SQL pode obter resultados diferentes. Esse problema é provavelmente causado por sintaxe ou uso inadequado. Para evitar esse problema, use a sintaxe corretamente. A seguir estão alguns exemplos de inconsistência de resultados de consulta junto com as soluções.

Os resultados da função de janela são classificados incompletamente

Cenário:

Na função de janela row_number(), a coluna c da tabela t3 é consultada após a ordenação. Os dois resultados da consulta são diferentes.

     
      
        
        select * from t3 order by 1,2,3;
 a | b | c 
---+---+--- 
 1 | 2 | 1 
 1 | 2 | 2 
 1 | 2 | 3
(3 rows) 

select c,rn from (select c,row_number() over(order by a,b) as rn from t3) where rn = 1; 
 c | rn 
---+---- 
1  |  1
(1 row) 
select c,rn from (select c,row_number() over(order by a,b) as rn from t3) where rn = 1;
 c | rn 
---+---- 
 3 |  1
(1 row)

       

     
    

Análise:

Como mostrado acima, execute sselect c,rn from (select c,row_number() over(order by a,b) as rn from t3) where rn = 1; duas vezes, os resultados são diferentes. Isso ocorre porque os valores duplicados 1 e 2 existem nas colunas de classificação a e b da função de janela, enquanto seus valores na coluna c são diferentes. Como resultado, quando o primeiro registro é obtido com base no resultado de classificação nas colunas a e b, os dados obtidos na coluna c são aleatórios, como resultado, os conjuntos de resultados são inconsistentes.

Solução:

Os valores na coluna c precisam ser adicionados à classificação.

     
        select c,rn from (select c,row_number() over(order by a,b,c) as rn from t3) where rn = 1;
 c | rn 
---+----
 1 |  1
(1 row)

Usar a classificação em subvisões/subconsultas

Cenário

Depois que a tabela test e a visão v são criadas, os resultados da consulta são inconsistentes quando a classificação é usada para consultar a tabela test em uma subconsulta.

     
        CREATE TABLE test(a serial ,b int);
INSERT INTO test(b) VALUES(1);
INSERT INTO test(b) SELECT b FROM test;
...
INSERT INTO test(b) SELECT b FROM test;
CREATE VIEW v as SELECT * FROM test ORDER BY a;

SQL de problema:

    
     
       
       select * from v limit 1;
 a | b
---+---
 3 | 1
(1 row)

select * from (select * from test order by a) limit 10;
 a  | b
----+---
 14 | 1
(1 row)

select * from test order by a limit 10;
 a | b
---+---
 1 | 1
(1 row)

      

    
   

Análise:

ORDER BY é inválida para subvisões e subconsultas.

Solução:

Não é aconselhável usar ORDER BY em subvisões e subconsultas. Para garantir que os resultados estejam em ordem, use ORDER BY na consulta mais externa.

LIMIT em subconsultas

Cenário: quando LIMIT é usada em uma subconsulta, os dois resultados da consulta são inconsistentes.

    
       select * from (select a from test limit 1 ) order by 1;
 a
---
 5
(1 row)

select * from (select a from test limit 1 ) order by 1;
 a
---
 1
(1 row)

Análise:

A LIMIT na subconsulta faz com que resultados aleatórios sejam obtidos.

Solução:

Para garantir a estabilidade do resultado final da consulta, não use LIMIT em subconsultas.

Usar String_agg

Cenário: quando string_agg é usada para consultar a tabela employee, os resultados da consulta são inconsistentes.

    
     
       
       select * from employee;
 empno | ename  |   job   | mgr  |      hiredate       |  sal  | comm | deptno 
-------+--------+---------+------+---------------------+-------+------+--------
  7654 | MARTIN | SALEMAN | 7698 | 2022-11-08 00:00:00 | 12000 | 1400 |     30
  7566 | JONES  | MANAGER | 7839 | 2022-11-08 00:00:00 | 32000 |    0 |     20
  7499 | ALLEN  | SALEMAN | 7698 | 2022-11-08 00:00:00 | 16000 |  300 |     30
(3 rows)

select count(*) from (select deptno, string_agg(ename, ',') from employee group by deptno) t1, (select deptno, string_agg(ename, ',') from employee group by deptno) t2 where t1.string_agg = t2.string_agg;
 count 
-------
     2
(1 row)

select count(*) from (select deptno, string_agg(ename, ',') from employee group by deptno) t1, (select deptno, string_agg(ename, ',') from employee group by deptno) t2 where t1.string_agg = t2.string_agg;
 count 
-------
     1
(1 row)

      

    
   

Análise:

A função string_agg é usada para concatenar dados em um grupo em uma linha. No entanto, se você usar string_agg(ename, ','), a ordem dos resultados concatenados precisa ser especificada. Por exemplo, na instrução anterior, select deptno, string_agg(ename, ',') from employee group by deptno;

pode produzir uma das seguintes:

    
       30 | ALLEN,MARTIN

Ou:

    
       30 |MARTIN,ALLEN

No cenário anterior, o resultado da subconsulta t1 pode ser diferente da subconsulta t2 quando deptno é 30.

Solução:

Adicione ORDER BY a String_agg para garantir que os dados sejam concatenados em sequência.

    
       select count(*) from (select deptno, string_agg(ename, ',' order by ename desc) from employee group by deptno) t1 ,(select deptno, string_agg(ename, ',' order by ename desc) from employee group by deptno) t2 where t1.string_agg = t2.string_agg;

Modo de compatibilidade de banco de dados

Cenário: os resultados da consulta de cadeias de caracteres vazias no banco de dados são inconsistentes.

banco de dados1 (compatível com TD):

    
       td=# select '' is null;
 isnull 
--------
 f
(1 row)

banco de dados2 (compatível com ORA):

    
       ora=# select '' is null;
 isnull 
--------
 t
(1 row)

Análise:

Os resultados da consulta de cadeia de caracteres vazia são diferentes porque a sintaxe da cadeia de caracteres vazia é diferente da da cadeia de caracteres nula em compatibilidade de banco de dados diferente.

Atualmente, o GaussDB(DWS) suporta três tipos de compatibilidade de banco de dados: Oracle, TD e MySQL. A sintaxe e o comportamento variam dependendo da compatibilidade. Para obter detalhes sobre as diferenças de compatibilidade, consulte Diferenças de compatibilidade de sintaxe entre Oracle, Teradata e MySQL

Bancos de dados em diferentes modos de compatibilidade têm diferentes problemas de compatibilidade. Você pode executar select datname, datcompatibility from pg_database; para verificar a compatibilidade do banco de dados.

Solução:

O problema é resolvido quando os modos de compatibilidade dos bancos de dados nos dois ambientes são definidos para o mesmo. O atributo DBCOMPATIBILITY de um banco de dados não oferece suporte a ALTER. Você só pode especificar o mesmo atributo DBCOMPATIBILITY ao criar um banco de dados.

O item de configuração behavior_compat_options para comportamentos de compatibilidade de banco de dados é configurado de forma inconsistente.

Cenário: os resultados do cálculo da função add_months são inconsistentes.

banco de dados1:

    
       select add_months('2018-02-28',3) from dual;
add_months
---------------------
2018-05-28 00:00:00
(1 row)

banco de dados2:

    
       select add_months('2018-02-28',3) from dual;
add_months
---------------------
2018-05-31 00:00:00
(1 row)

Análise:

Alguns comportamentos variam de acordo com o item de configuração de compatibilidade de banco de dados behavior_compat_options. Para obter detalhes sobre as opções de parâmetro, consulte behavior_compat_options.

O end_month_calculate em behavior_compat_options controla a lógica de cálculo da função add_months. Se este parâmetro for especificado e o Day de param1 indicar o último dia de um mês menor que result, o Day no resultado do cálculo será igual ao result.

Solução:

O parâmetro behavior_compat_options deve ser configurado consistentemente. Este parâmetro é do tipo USERSET e pode ser definido no nível da sessão ou modificado no nível do cluster.

Os atributos da função definida pelo usuário não estão configurados corretamente.

Cenário: quando a função personalizada get_count() é invocada, os resultados são inconsistentes.

    
       CREATE FUNCTION get_count() returns int
SHIPPABLE
as $$
declare
    result int;
begin
result = (select count(*) from test); --test table is a hash table.
	return result;
end;
$$
language plpgsql;

Chame essa função.

    
       SELECT get_count();
 get_count 
-----------
      2106
(1 row)

SELECT get_count() FROM t_src;
 get_count 
-----------
      1032
(1 row)

Análise:

Esta função especifica o atributo SHIPPABLE. Quando um plano é gerado, a função o empurra para DNs para execução. A tabela de teste definida na função é uma tabela de hash. Portanto, cada DN tem apenas parte dos dados da tabela, o resultado retornado por select count(*) from test; não é o resultado de dados completos na tabela de teste. O resultado esperado muda depois que from é adicionado.

Solução:

Use um dos seguintes métodos (o primeiro método é recomendado):

Altere a função para não empurrar para baixo: ALTER FUNCTION get_count() not shippable;
Altere a tabela usada na função para uma tabela de replicação. Desta forma, os dados completos da tabela são armazenados em cada DN. Mesmo que o plano seja empurrado para DNs para execução, o conjunto de resultados será o esperado.

Usar a tabela não registrada

Cenário:

Depois que uma tabela não registrada é usada e o cluster é reiniciado, o conjunto de resultados de consulta associado é anormal e alguns dados estão ausentes na tabela não registrada.

Análise:

Se max_query_retry_times for definido como 0 e a palavra-chave UNLOGGED for especificada durante a criação da tabela, a tabela criada será uma tabela não registrada. Os dados gravados em tabelas não registradas não são gravados no log de gravação antecipada, o que os torna consideravelmente mais rápidos do que as tabelas comuns. No entanto, uma tabela não registrada é automaticamente truncada após uma falha ou desligamento impuro, incorrendo em riscos de perda de dados. O conteúdo de uma tabela não registrada também não é replicado para servidores em espera. Quaisquer índices criados em uma tabela não registrada também não são registrados automaticamente. Se o cluster for reiniciado inesperadamente (reinicialização do processo, falha do nó ou reinicialização do cluster), alguns dados na memória não serão liberados nos discos em tempo hábil e alguns dados serão perdidos, fazendo com que o conjunto de resultados seja anormal.

Solução:

A segurança das tabelas não registradas não pode ser assegurada se o cluster for defeituoso. Na maioria dos casos, as tabelas não registradas são usadas apenas como tabelas temporárias. Se um cluster estiver com defeito, você precisará reconstruir a tabela não registrada ou fazer backup dos dados e importá-los para o banco de dados novamente para garantir que os dados estejam normais.

Tópico principal: Uso do banco de dados

Feedback

Esta página foi útil?

Sim Não

Deixar um comentário

Obrigado por seus comentários. Estamos trabalhando para melhorar a documentação.

O sistema está ocupado. Tente novamente mais tarde.

Quais dos seguintes problemas você encontrou?

O conteúdo é inconsistente com a UI do produto

Descrições pouco claras

Falta de exemplos ou código

Passos incorretos

Não encontro o que preciso

Falta de melhores práticas

Feedback (opcional)

0/500

Selecione pelo menos um tipo de problema e insira seus comentários ou sugestões.

Insira um máximo de 500 caracteres.

Enviar Cancelar