All perguntas(dba)

nvarchar(100)contém 100 pares de bytes , conforme documentado aqui . LEFT([Your String], 100)trunca sua string para 100 caracteres conforme documentado aqui . Estes não são iguais.

Tolamente, usei LEFT([Your String], 100)na esperança de me manter [Your String]dentro de mim nvarchar(100). Quais são as abordagens idiomáticas para resolver este problema corretamente? Pensei em usar CAST, mas não me sinto confortável em truncar implicitamente uma string.

Cenário

Eu executo uma consulta longa e complexa que retorna mais de 30 campos e mais de 77.000 linhas no SSMS. Os resultados estão na grade. Os resultados são todos com muito texto. A grade SSMS começa a ser preenchida com resultados após alguns segundos (3 a 4) segundos, mas o tempo de execução da consulta é de 2 minutos. A maior parte desses 2 minutos são resultados anexados à grade no SSMS.

Questões)

Quando a consulta foi "concluída"? Isso foi feito nos primeiros 3 a 4 segundos quando as linhas começaram a ser anexadas à grade do SSMS? O restante dos 1 minuto e 56 segundos é apenas a atualização da interface do usuário da grade com os resultados? Se a consulta estiver "concluída" após 3 a 4 segundos, não devo tentar otimizá-la, correto? Por outro lado, se a consulta não for feita até que a execução pare no SSMS (os dois minutos completos), devo poder otimizá-la.

Estou executando um data warehouse em uma instância do AWS RDS PostgreSQL. A maior parte do trabalho pesado é feita durante o lote noturno e muitas vezes usamos uma estratégia de reconstrução TRUNCATE, também para tabelas grandes (100 milhões de linhas).

Isso parece causar problemas com o autovacuum, entre 2 e 4 do lote noturno, 7 em cada 10 das instruções TOP SQL são instruções VACUUM ANALYZE para tabelas grandes: e elas estão abraçando meu sistema RDS e reduzindo o equilíbrio de bytes para 0, após o qual a máquina desacelera enormemente:

Obviamente seria mais sensato adiar a ANÁLISE DE VÁCUO para um período posterior, quando a máquina estiver quase ociosa.

Depois de ler alguma documentação, posso pensar em duas estratégias para fazer isso:

1. desligue o Autovacuum para essas tabelas grandes e agende um processo que execute o Vacuum mais tarde
2. defina o autovacuum_cost_delaypara um valor sensato. já que isso adiaria o processamento do Vácuo em geral (ou talvez o definiria com um valor razoável apenas para essas tabelas).

No entanto, qual é um valor sensato neste caso? Eu li que o padrão é 2 milissegundos. Quanto maior é o valor sensato de 200ms? 10 segundos? 1 minuto? 60 minutos?

Estou procurando um valor sensato para começar a testar ou outro conselho que possa me ajudar.

Nota. a máquina tem 2cpu, 16GB m6g.large e estas são as configurações atuais para os parâmetros relacionados ao autovauccum:

Informações extras @jjanes sim, mal atinge o equilíbrio de bytes 0, no entanto, este é um equilíbrio cuidadoso que realmente consegui alcançar. Eu regularmente encontrava a situação em que demorava muito para me recuperar de uma situação que, na verdade, caía para 0. Exemplo

Minha máquina então começa a acumular latência de leitura/gravação e DiskQueueDepth também

O carregamento em massa à noite preocupa muitas mesas (atualmente ~900), que são todas carregadas/transformadas através de jobs entre 23h e 6h30, sendo o horário de maior movimento entre 2h e 4h. Muitas mesas são pequenas, apenas algumas são bastante grandes.

@jjanes & @frank-heikens, qual versão posterior faz diferença? aqui estão duas capturas de tela da situação antes e depois da migração de 14 para 15: Antes: Depois :

Atualização Implementada sugestão de @Laurence Albe. Observações:

Equilíbrio de bytes muito melhor:

O banco de dados carrega muito mais uniformemente:

Estou tentando duplicar um banco de dados de um banco de dados ativo, mas parece que minha conexão está bloqueada no meu auxiliar. Estou usando o ASM just4info.

Banco de dados de destino:

ouvinte.ora:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = MELISA)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER=
   (SID_LIST=
       (SID_DESC=
          (SID_NAME=MELISA)
          (ORACLE_HOME=/u01/app/oracle/product/19/dbhome_1)
        )
    )


ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON              # line added by Agent
VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON            # line added by Agent

tnsnames.ora:

    MELISA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MELISA)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MELISA)
    )
  )

LISTENER_MELISA =
  (ADDRESS = (PROTOCOL = TCP)(HOST = MELISA)(PORT = 1521))

PELISA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = PELISA)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PELISA)
    )
  )

LISTENER_PELISA =
  (ADDRESS = (PROTOCOL = TCP)(HOST = PELISA)(PORT = 1521))

Auxiliar:

ouvinte.ora:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = PELISA)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER=
   (SID_LIST=
       (SID_DESC=
          (SID_NAME=PELISA)
          (ORACLE_HOME=/u01/app/oracle/product/19/dbhome_1)
        )
    )

tnsnames.ora

LISTENER_PELISA =
  (ADDRESS = (PROTOCOL = TCP)(HOST = PELISA)(PORT = 1521))


PELISA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = PELISA)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PELISA)
    )
  )

MELISA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MELISA)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MELISA)
    )
  )

LISTENER_MELISA =
  (ADDRESS = (PROTOCOL = TCP)(HOST = MELISA)(PORT = 1521))

Status do lsnrctl:

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                05-JAN-2024 09:45:43
Uptime                    0 days 0 hr. 5 min. 15 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /u01/app/oracle/diag/tnslsnr/PELISA/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=PELISA)(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "+ASM_DG_DATA" has 1 instance(s).
  Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "+ASM_DG_FRA" has 1 instance(s).
  Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "PELISA" has 1 instance(s).
  Instance "PELISA", status BLOCKED, has 1 handler(s) for this service...
The command completed successfully

O banco de dados auxiliar está em nomount usando spfile, e ao tentar conectar ao rman recebo o seguinte erro:

connected to target database: MELISA (DBID=3534003804)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04006: error from auxiliary database: ORA-12528: TNS:listener: all appropriate instances are blocking new connections

Não tenho certeza do que pode estar errado aqui, parei o firewall, pois é uma máquina de teste.

Desde já, obrigado.

Estou tentando mudar uma partição de tabela para uma tabela temporária com a seguinte consulta:

create partition function [PFCT_T](datetime2) as range right for values ()
create partition scheme [PSCH_T] as partition [PFCT_T] all to ([primary])
    
create table T(A1 datetime2 not null, A2 int not null) on [PSCH_T](A1)
create clustered columnstore index [CIX_T] on dbo.T
    
insert into T(A1, A2) values ('2024-01-01 00:00:00', 1)
    
select top 0 * into #T from T
create clustered columnstore index [CIX_#T] on #T
    
alter table T switch partition 1 to #T
--Results in:
--Msg 608, Level 16, State 1, Line 15
--No catalog entry found for partition ID 5620492390548766720 in database 23. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption.

Não é possível mudar uma partição para uma tabela temporária (funciona com tabelas normais) ou perdi alguma coisa?

Eu tenho uma tabela que possui índice exclusivo:

CREATE UNIQUE INDEX IF NOT EXISTS tb_sha256_key_idx ON blob_props (sha256, key);

Quero alterá-lo para chave primária durante a migração do banco de dados e há duas maneiras:

1. ALTER TABLE tb ADD CONSTRAINT tb_pkey PRIMARY KEY USING INDEX tb_sha256_key_idx;

2. DROP INDEX tb_sha256_key_idxe entãoALTER TABLE tb ADD PRIMARY KEY (sha256, key);

sha256e keynão são colunas nulas (portanto, deve funcionar bem).

Tenho algumas preocupações em relação às duas abordagens e estou debatendo qual é a abordagem correta durante uma migração de banco de dados:

A segunda abordagem é melhor porque, ao descartar/criar, melhoraremos drasticamente o fator de agrupamento do índice e seu tamanho devido à fragmentação. É preferível do ponto de vista do desempenho. Mas criar um índice em uma tabela grande causaria arquivos temporários grandes (é por isso que usamos REINDEX na maioria das vezes e criamos novos índices apenas como último recurso).

Deseja aprofundar a discussão e obter algumas reivindicações e/ou mais opiniões sobre esse cenário.

A consulta a seguir converte uma única string de CSV compactado que representa 13 mil linhas por 2 colunas. A coluna A é um bigint. A coluna B é um inteiro pequeno.

declare
    @dataCsv nvarchar(max) = '29653,36,19603,36,19604,36,29654,36';  -- abbreviated, actually 13k rows

  with Input as
  (
      select Value,
             Row = row_number() over (order by (select null)) - 1
      from string_split(@dataCsv, ',') o
  )
  --insert into PubCache.TableName
  select 78064 as CacheId,
         convert(bigint, i.Value) as ObjectId,
         convert(smallint, i2.Value) as BrandId
    from Input i
    inner hash join Input i2    -- hash to encourage string_split() only once per column
      on i2.Row = i.Row + 1
    where i.Row % 2 = 0
    order by i.Row

Plano de Execução: https://www.brentozar.com/pastetheplan/?id=By0hYPmd6

Conforme mostrado no plano, a avaliação de convert() está ocorrendo antes da junção, então às vezes (dependendo do comprimento da entrada), ela falha com

A conversão do valor nvarchar '37645' estourou uma coluna INT2. Use uma coluna inteira maior.

Alterar temporariamente a conversão de smallint para int permite que a consulta seja concluída e a inspeção da saída da coluna BrandId mostra que ela sempre contém apenas o valor '36' para este exemplo.

Existe uma maneira simples de atrasar o convert(smallint, i2.Value) até depois da junção, para que apenas as posições CSV esperadas sejam convertidas?

Sei que existem outras maneiras de compactar um fluxo de string (como usar múltiplas variáveis ​​ou entrelaçar diferentes caracteres divididos, etc.), mas não estou interessado em resolver este exemplo dessa forma para fins desta questão. Obrigado!

Código de amostra:

show timezone;
   TimeZone    
---------------
 Europe/Berlin
(1 row)

create table foo (ts timestamp without time zone);
insert into foo values ('2023-10-28 23:58:00');
insert into foo values ('2023-10-29 00:58:00');
insert into foo values ('2023-10-29 01:58:00');

select (ts at time zone 'utc' at time zone 'Europe/Berlin')::timestamptz as x from foo order by x;
           x            
------------------------
 2023-10-29 01:58:00+02
 2023-10-29 02:58:00+01   <<<<------
 2023-10-29 02:58:00+01
(3 rows)

Caso a linha marcada não seja

 2023-10-29 02:58:00+02

?

Meu entendimento é que o relógio retrocede às 3h na Europa/Berlim, portanto UTC '2023-10-29 00:58:00'deve corresponder a 02:58:00 antes do relógio voltar, portanto ainda +02, ou CEST, se preferir. Estou errado?

Criei um trabalho no SQL Server. Este trabalho executa a seguinte instrução em intervalos regulares:

Select NationalIDNumber from HumanResources.Employee where BusinessEntityID = '1'

Quero salvar o resultado desta consulta em um arquivo txt. Cliquei em Avançado na guia Etapa do trabalho que criei. Escrevi o caminho lá, mas quando o job foi executado nenhum registro foi adicionado ao arquivo txt.

O que mais devo fazer para adicionar o resultado do trabalho ao txt?

Guia Avançado: Arquivo de Saída ->D:\Data2\JobOutput.txt

A visualização do sistema sys.dm_db_index_usage_statspossui diversas colunas que refletem o uso do índice pelas consultas do sistema. Mas o que isso significa? Por que o sistema consulta minha tabela?

A documentação não é particularmente útil: