All perguntas(dba)

Os dados

Digamos que eu tenha uma grade representando todas as pessoas em uma sala e as conversas que elas têm quando falam entre si.

O banco de dados

Inicialmente considerei apenas fazer tabelas regulares de PeopleeConversations

A Conversationsmesa seria uma chave etopic participant1 participant2

O dilema

A ordem dos participantes é totalmente irrelevante. Uma simples pergunta “Sobre o que Rachel e Brian conversam” torna-se uma consulta complicada de executar.

Portanto, uma de duas coisas deve ser feita:

1. Dados redundantes são adicionados ao banco de dados: (Rachel e Brian) ou (Brian e Rachel)
2. Uma consulta ridiculamente complicada é necessária para consultar os dados não redundantes porque você não sabe se Rachel é participante1 ou participante2.

Seguir com 1 acima cria um modelo de banco de dados O (n ^ 2) insustentável, enquanto 2 parece um pesadelo de DBA tentando consultar dados significativos.

A questão

Como faço para modelar uma estrutura de dados como esta? O SQL é a ferramenta certa para o trabalho ou devo pesquisar algo totalmente diferente?

Cenário

Eu tenho um produto de software de middleware chamado Pro2SQL da Progress, copiando dados de um banco de dados Progress para um SQL Server em tempo real. Pro2SQL gerencia o esquema do SQL Server por meio do middleware. Os únicos índices criados no SQL Server pelo Pro2SQL são índices de ID de linha exclusivos e não agrupados. Posso ignorar completamente esse ID de linha em minhas consultas, pois ele é usado exclusivamente para simultaneidade Pro2SQL.

Algumas das tabelas contêm mais de 100 milhões de linhas, então preciso criar índices. Em cada tabela copiada do Progress para o SQL Server, existe um campo “domínio”. Este campo possui um de dois valores de três caracteres cada. Vamos chamá-los de 'ABC' ou 'XYZ'. No lado do banco de dados Progress, este domaincampo faz parte do índice.

Pergunta

Adicionar o domaincampo como parte de um índice de vários campos no lado do SQL Server agrega algum valor ou pode piorar as coisas? Por exemplo, posso ter o seguinte índice não clusterizado de vários campos em uma tabela (observe que esses campos são o que torna as linhas na tabela do banco de dados Progress exclusivas):

• isb_eu_nbr(muito seletivo)
• isb_part(muito seletivo)
• isb_serial(muito seletivo)
• isb_ref(moderadamente seletivo)
• isb_domain(extremamente não seletivo, apenas 'ABC' ou 'XYZ', a fonte da minha pergunta)

Esta tabela terá cerca de 500.000+ linhas.

Uso

Todas as consultas serão consultas somente leitura. Não haverá inserções, atualizações ou exclusões. Eles são tratados pelo middleware Pro2SQL. Em todas as minhas consultas, terei que adicionar na WHEREcláusula o seguinte:

/* WHERE <tableAbbr>_domain = 'ABC' */

/* Example */
WHERE
    /* Conditions 1 through N */
    AND isb_domain = 'ABC'

/* Another Example, with JOINed tables */
WHERE
    /* Conditions 1 through N */
    AND isb_domain = 'ABC'
    AND ls_domain = 'ABC'
    AND pt_domain = 'ABC'

outras considerações

O fornecedor, Progress, indica que, como há atualizações em tempo real acontecendo constantemente ao longo do dia útil, todas as consultas devem ser sem bloqueio. Então eles realmente sugerem(!!!) NOLOCK. Habilitamos SNAPSHOTno banco de dados, então todas as consultas conectadas diretamente ao servidor serão executadas com SET TRANSATION ISOLATION LEVEL SNAPSHOT, e todas as consultas executadas através de servidores vinculados serão executadas com SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED(aceitando os efeitos colaterais).

ATUALIZADA

Descobri que posso criar índices agrupados e não exclusivos nas tabelas do SQL Server. Além disso, com as sugestões abaixo, posso criar índices filtrados não exclusivos e não agrupados em cluster, onde o filtro estaria no campo <abc>_domainde cada tabela. Então minha pergunta se transformou em:

Devo criar índices agrupados não exclusivos que correspondam aos campos do banco de dados Progress quanto à exclusividade, menos os <abc>_domaincampos e, em seguida, criar índices filtrados não exclusivos e não agrupados que incluam o <abc>_domaincampo em cada tabela?

Eu entendo que um sim/não rígido nem sempre é viável sem realmente ver o banco de dados e os dados. Ainda farei testes de desempenho. Estou procurando mais uma resposta "Eu começaria com ...".

Estou tentando fazer backup e restaurar um esquema de um servidor remoto para um sistema local. Embora pg_dumpe pg_restorerelate a mesma versão, o último falha com o familiar erro "Versão não suportada" (log abaixo). Já vi esse erro antes, quando pg_restoreé uma versão mais antiga que pg_dump, mas nunca quando as versões correspondem. O que poderia ser a causa?

$ psql -h server.somewhere -p 5432 -U user -d database
Password for user user:
psql (16.1 (Ubuntu 16.1-1.pgdg22.04+1), server 14.10)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

database=> SELECT version();
                                                 version
----------------------------------------------------------------------------------------------------------
 PostgreSQL 14.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 row)

database=> \q

$ pg_dump --version
pg_dump (PostgreSQL) 14.10 (Ubuntu 14.10-1.pgdg22.04+1)

$ pg_restore --version
pg_restore (PostgreSQL) 14.10 (Ubuntu 14.10-1.pgdg22.04+1)

$ pg_dump -h server.somewhere -p 5432 -U user database -n schema_new -F t > ~/temp/schema_new_2024-01-29.backup

$ pg_restore -d wosis ~/temp/schema_new_2024-01-29.backup
pg_restore: error: unsupported version (1.15) in file header

Em um dos meus servidores, há muitos bancos de dados dos quais faço backup com o script do Ola. Às vezes acontece que a tarefa de backup falhou. Mas como muitas mensagens foram impressas na mensagem do trabalho não consigo ver a mensagem de erro. Editei o script para evitar mensagens extras. Mas as mensagens incorporadas que o próprio mecanismo sql produz não são evitáveis.

Quero dizer esse tipo de mensagem:

Processed 504 pages for database 'ODS', file 'ODS' on file 1.
Processed 16 pages for database 'ODS', file 'ODS_Regualr_Data' on file 1.
Processed 16 pages for database 'ODS', file 'ODS_SALES_DATA' on file 1.

Existe alguma maneira de dizer para não imprimi-los?

Suponha que eu tenha muitas tabelas vinculadas por uma cadeia de ON DELETE CASCADEchaves estrangeiras. Até onde sei e experiência, a exclusão de uma tabela não me dá nenhum aviso de que de fato afetei várias tabelas. Por exemplo, se a exclusão de uma linha table1causar a exclusão de 500 linhas, table2tudo o que o SSMS me dirá é

(1 linha afetada)

Existe alguma maneira de saber quantas tabelas/linhas DELETErealmente foram alteradas? Parece que, em teoria, eu poderia excluir uma linha de uma tabela em um banco de dados suficientemente maligno e, sem saber, excluir 99% dos dados do banco de dados.

A documentação menciona Invoke-DbaQuerymuitas outras funções semelhantes

Esta função é um comando wrapper Invoke-DbaAsync, que por sua vez é baseado em Invoke-SqlCmd2. Ele foi projetado para ser mais conveniente de usar em um pipeline e para se comportar de maneira consistente com o restante de nossas funções.

É claro que existem outras maneiras de consultar SQL no PowerShell, por exemplo Invoke-Sqlcmd.

Quais são os benefícios de usar Invoke-DbaQueryem vez de Invoke-Sqlcmd, Invoke-Sqlcmd2e Invoke-DbaAsync?

Suponha que criamos uma tabela e inserimos um registro com o seguinte script.

CREATE TABLE your_table ( your_column VARCHAR COLLATE "tr-TR-x-icu" );
INSERT INTO your_table(your_column) VALUES ('Gider');

Quando executei o script revisado a seguir, obtive o resultado 'diferente'. O resultado deve ser 'igual', pois eu uso o agrupamento "tr-TR-x-icu" da coluna e a parte superior do texto 'Gider' é 'GİDER' em turco.

SELECT 
CASE WHEN UPPER(your_column)=UPPER('Gider') THEN 'equal' 
     ELSE 'not equal' 
END AS result 
FROM your_table;

Quando executei o script a seguir, obtive a resposta correta (ou seja, 'igual').

SELECT 
CASE WHEN UPPER(your_column)=UPPER('Gider' COLLATE "tr-TR-x-icu") THEN 'equal' 
     ELSE 'not equal' 
END AS result 
FROM your_table;

Seria bom se houvesse um método para definir esta propriedade de agrupamento dentro desta sessão.

Por exemplo, adicionando like SET COLLATE...logo antes da consulta.

Desta forma, em vez de escrever UPPER(your_column)=UPPER('Gider' COLLATE "tr-TR-x-icu"), bastaria apenas escrever UPPER(your_column)=UPPER('Gider').

Eu ficaria feliz se alguém pudesse oferecer uma solução.
Muitas felicidades.

Estou tentando entender por que uma instrução de atualização não faz com que o comprimento da lista de histórico (HLL) aumente quando o banco de dados tem alta carga de gravação. A instrução Select faz com que o HLL cresça no mesmo cenário.

Cenário 1: HLL não está crescendo

1. Banco de dados MySQL possui 1 tabela com 2 colunas (1 chave primária)
2. Usando o sysbench para executar atualizações e inserir instruções nesta tabela com 8 threads
3. Simultaneamente com o carregamento do sysbench, tendo uma transação de longa duração:

> START TRANSACTION;
> UPDATE t1 SET c2 = 'val' WHERE c1 != 'DONE'.
[leaving this terminal open without committing]

Cenário 2: HLL está crescendo (conforme esperado)

1. Mesma configuração acima: 1 tabela e sysbench executando instruções de gravação na tabela.
2. Simultaneamente com o carregamento do sysbench, a transação de longa execução é apenas uma instrução SELECT:

> START TRANSACTION;
> SELECT * from t1 WHERE c1 != 'DONE'.
[leaving this terminal open without committing]

Expectativa : O HLL deverá crescer rapidamente em ambos os cenários, uma vez que ambos os cenários deverão utilizar uma visualização de leitura.

Observação Real : O HLL cresce rapidamente apenas no Cenário 2. Para o cenário 1, o HLL permanece quase constante.

Pergunta: Por que esse comportamento? Por que uma instrução de atualização com a condição where não faz com que o HLL cresça?

Se eu tiver um índice com fator de preenchimento padrão de 100% e as modificações resultarem em uma grande fragmentação interna (divisões de páginas, espaço livre etc.), de modo que muitas páginas fiquem cerca de 60% cheias em vez de 100%, seria uma reconstrução/reorganização de índice compacta os dados em menos páginas de dados, resultando em mais espaço disponível relatado no banco de dados?

Se o anterior for verdadeiro, faz sentido reorganizar os índices antes de executar uma operação de redução para maximizar o espaço ganho pela redução (seguida por outra reorganização após a redução para reduzir a fragmentação causada pela redução)?

Finalmente, o DBCC Shrinkfile compacta as páginas de dados da mesma forma que uma reconstrução ou apenas move as páginas de dados?

Gostaria de fornecer acesso a alguns grupos de usuários para visualizar as classificações de sensibilidade. Atualmente ele retorna resultados em branco na ferramenta de relatórios ou consultando diretamente a tabela sys.sensitivity_classifications.

Qual é o conjunto mínimo de permissões, padrão ou personalizado, que pode ser usado para fornecer uma visualização somente leitura?