All perguntas(dba)

Por que essas duas SELECTinstruções resultam em uma ordem de classificação diferente?

USE tempdb;
CREATE TABLE dbo.OddSort 
(
    id INT IDENTITY(1,1) PRIMARY KEY
    , col1 NVARCHAR(2)
    , col2 NVARCHAR(2)
);
GO
INSERT dbo.OddSort (col1, col2) 
VALUES (N'e', N'eA')
    , (N'é', N'éB')
    , (N'ë', N'ëC')
    , (N'è', N'èD')
    , (N'ê', N'êE')
    , (N'ē', N'ēF');
GO

SELECT * 
FROM dbo.OddSort 
ORDER BY col1 COLLATE Latin1_General_100_CS_AS;

╔════╦══════╦══════╗
║ id ║ col1 ║ col2 ║
╠════╬══════╬══════╣
║ 1 ║ e ║ eA ║
║ 2 ║ é ║ éB ║
║ 4 ║ è ║ èD ║ -- deve ser id 3?
║ 5 ║ ê ║ êE ║
║ 3 ║ ë ║ ë C ║
║ 6 ║ ē ║ ēF ║
╚════╩══════╩══════╝

SELECT * 
FROM dbo.OddSort 
ORDER BY col2 COLLATE Latin1_General_100_CS_AS;

╔════╦══════╦══════╗
║ id ║ col1 ║ col2 ║
╠════╬══════╬══════╣
║ 1 ║ e ║ eA ║
║ 2 ║ é ║ éB ║
║ 3 ║ ë ║ ë C ║
║ 4 ║ è ║ èD ║
║ 5 ║ ê ║ êE ║
║ 6 ║ ē ║ ēF ║
╚════╩══════╩══════╝

Estou tendo problemas para encontrar respostas com várias pesquisas na Internet e no Google para o problema do MySQL Workbench que estou enfrentando.

Não encontrei nenhuma resposta sobre como fazer isso funcionar novamente.

Aqui está o erro do MySQL Workbench Estou tendo problemas para solucionar problemas que preciso de ajuda

mysql workbench falhou ao conectar em localhost:3306 com erro de conexão ssl root do usuário: ssl é necessário, mas o servidor não o suporta

Da MongoDBdocumentação é mencionado que:

Quando você precisa apenas de um subconjunto de campos de documentos, pode obter melhor desempenho retornando apenas os campos necessários

Como os campos de filtragem afetam o desempenho? O desempenho está relacionado ao tamanho dos dados que são transmitidos pela rede? ou o tamanho dos dados que serão mantidos na memória? Como exatamente esse desempenho é melhorado? Qual é esse desempenho que está sendo mencionado na documentação?

Eu tenho consultas lentas do MongoDB. O retorno de um subconjunto afeta minha consulta lenta (tenho índice composto no campo)?

Tenho a seguinte configuração:

• uma máquina host que executa três contêineres docker:
  • MongoDB
  • Redis
  • Um programa usando os dois contêineres anteriores para armazenar dados

Tanto o Redis quanto o MongoDB são usados ​​para armazenar grandes quantidades de dados. Eu sei que o Redis precisa manter todos os seus dados na RAM e estou bem com isso. Infelizmente, o que acontece é que o mongo começa a ocupar muita RAM e assim que a RAM do host está cheia (estamos falando de 32 GB aqui), o mongo ou o Redis travam.

Eu li as seguintes perguntas anteriores sobre isso:

1. Limite o uso de RAM do MongoDB : aparentemente a maior parte da RAM é usada pelo cache do WiredTiger
2. Limite de memória do MongoDB : aqui aparentemente o problema eram os dados de log
3. Limite o uso de memória RAM no MongoDB : aqui eles sugerem limitar a memória do mongo para que ele use uma quantidade menor de memória para seu cache/logs/dados
4. MongoDB usando muita memória : aqui eles dizem que é o sistema de cache WiredTiger que tende a usar o máximo de RAM possível para fornecer acesso mais rápido. Eles também afirmamit's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
5. Existe alguma opção para limitar o uso de memória do mongodb? : cache novamente, eles também adicionamMongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions
6. Relação de índice/RAM do MongoDB : citação:MongoDB keeps what it can of the indexes in RAM. They'll be swaped out on an LRU basis. You'll often see documentation that suggests you should keep your "working set" in memory: if the portions of index you're actually accessing fit in memory, you'll be fine.
7. como liberar o cache que é usado pelo MongoDB? : mesma resposta que em 5.

Agora, o que parece entender de todas essas respostas é que:

1. Para um acesso mais rápido, seria melhor que o mongo ajustasse todos os índices na RAM. No entanto, no meu caso, estou bem com índices residindo parcialmente no disco, pois tenho um SSD bastante rápido.
2. A RAM é usada principalmente para armazenamento em cache pelo mongo.

Considerando isso, eu esperava que o mongo tentasse usar o máximo de espaço de RAM possível, mas sendo capaz de funcionar também com pouco espaço de RAM e buscar a maioria das coisas do disco. No entanto, limitei a memória do contêiner do Mongo Docker (a 8 GB, por exemplo), usando --memorye --memory-swap, mas em vez de buscar coisas do disco, o mongo simplesmente travou assim que ficou sem memória.

Como posso forçar o mongo a usar apenas a memória disponível e buscar do disco tudo o que não cabe na memória?

Tenho uma tabela assim:

CREATE TABLE Updates
(
    UpdateId INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
    ObjectId INT NOT NULL
)

Essencialmente, rastreando atualizações de objetos com um ID crescente.

O consumidor desta tabela selecionará um bloco de 100 IDs de objetos distintos, ordenados por UpdateIde a partir de um UpdateId. Essencialmente, mantendo o controle de onde parou e, em seguida, consultando as atualizações.

Descobri que isso é um problema de otimização interessante porque só consegui gerar um plano de consulta maximamente ideal escrevendo consultas que fazem o que eu quero devido aos índices, mas não garantem o que eu quero:

SELECT DISTINCT TOP 100 ObjectId
FROM Updates
WHERE UpdateId > @fromUpdateId

Onde @fromUpdateIdé um parâmetro de procedimento armazenado.

Com um plano de:

SELECT <- TOP <- Hash match (flow distinct, 100 rows touched) <- Index seek

Devido à busca no UpdateIdíndice que está sendo usado, os resultados já são bons e ordenados do menor para o maior ID de atualização, como eu quero. E isso gera um plano de fluxo distinto , que é o que eu quero. Mas o ordenamento obviamente não é um comportamento garantido, então não quero usá-lo.

Esse truque também resulta no mesmo plano de consulta (embora com um TOP redundante):

WITH ids AS
(
    SELECT ObjectId
    FROM Updates
    WHERE UpdateId > @fromUpdateId
    ORDER BY UpdateId OFFSET 0 ROWS
)
SELECT DISTINCT TOP 100 ObjectId FROM ids

No entanto, não tenho certeza (e suspeito que não) se isso realmente garante o pedido.

Uma consulta que eu esperava que o SQL Server fosse inteligente o suficiente para simplificar era essa, mas acaba gerando um plano de consulta muito ruim:

SELECT TOP 100 ObjectId
FROM Updates
WHERE UpdateId > @fromUpdateId
GROUP BY ObjectId
ORDER BY MIN(UpdateId)

Com um plano de:

SELECT <- Top N Sort <- Hash Match aggregate (50,000+ rows touched) <- Index Seek

Estou tentando encontrar uma maneira de gerar um plano ideal com uma busca de índice ativada UpdateIde um fluxo distinto para remover ObjectIds duplicados. Alguma ideia?

Dados de amostra, se você quiser. Os objetos raramente terão mais de uma atualização e quase nunca devem ter mais de uma em um conjunto de 100 linhas, e é por isso que estou atrás de um fluxo distinct , a menos que haja algo melhor que eu não conheça? No entanto, não há garantia de que um único ObjectIdnão terá mais de 100 linhas na tabela. A tabela tem mais de 1.000.000 de linhas e espera-se que cresça rapidamente.

Suponha que o usuário deste tenha outra maneira de encontrar o próximo apropriado @fromUpdateId. Não há necessidade de devolvê-lo nesta consulta.

Estou envolvido em um novo projeto, onde tenho que criar um cubo de dados a partir do sistema de banco de dados relacional existente.

Eu entendi que, o sistema existente não foi projetado adequadamente, não sei por onde começar.

Minha pergunta são:

• Qual é a diferença entre o Star Schema e o cubo de dados?
• Por onde devo começar? Do esquema em estrela ou diretamente do cubo de dados?
• O cubo de dados é gerado a partir do esquema em estrela?

Tenho pouca experiência em modelagem de dados relacionais, esta questão pode parecer muito básica, tentei descobrir com poucos recursos, ainda não está claro. Por favor, dê seus conselhos e sugestões?

Se eu perdi algo muito importante relacionado a esta pergunta, por favor, compartilhe seus pensamentos sobre isso também.

Eu tenho uma consulta SQL abaixo, quero selecionar vários valores usando o likeoperador.

Minha consulta está correta?

SELECT top 1 employee_id, employee_ident, utc_dt, rx_dt 
FROM       employee
INNER JOIN employee_mdata_history 
ON         employee.ident=employee_mdata_history.employee_ident 
WHERE      employee_id like 'emp1%' , 'emp3%' 
ORDER BY   rx_dt desc

Se não, alguém pode me corrigir?

Minha tabela tem uma grande quantidade de dados começando com 'emp1'e 'emp3'. Posso filtrar o resultado por top 3 "emp1" e top 2 "emp3" com base em rx_dt?

Existe uma maneira de 'injetar' uma estimativa de cardinalidade em um otimizador do SQL Server (qualquer versão)?

ou seja, algo semelhante à dica de cardinalidade do Oracle.

Minha motivação é impulsionada pelo artigo Quão bons são os otimizadores de consulta, realmente? ^[1] , onde testam a influência do estimador de cardinalidade na seleção de um plano ruim. Portanto, seria suficiente se eu pudesse forçar o SQL Server a 'estimar' as cardinalidades precisamente para consultas complexas.

^[1] Leis, Victor, et al. "Quão bons são os otimizadores de consulta, realmente?"
Anais do Fundo VLDB 9.3 (2015): 204-215.

Eu não tentei usar a transação do MySQL antes, só quero esclarecer uma coisa.

Se dois usuários executassem uma consulta no momento exato, como o MySQL lidaria com isso? por exemplo, os usuários estão tentando atualizar um registro.

user1: atualização do conjunto da tabela coluna = coluna - 4 onde column_id = 1;

user2: atualização do conjunto da tabela coluna = coluna - 7 onde column_id = 1;

Agora, se eu usar transações, o MySQL escolherá qual consulta será executada primeiro e bloqueará o segundo usuário até que a primeira consulta seja confirmada? Isso será um bloqueio de tabela ou um bloqueio de linha?

E se um terceiro usuário emitir uma instrução select? Qual será o valor que o MySQL retornará?

PS isso será no Innodb.

Em algumas ocasiões, e depois de fazer um enorme update, insertou deletede uma tabela, iniciei um VACUUM FULL ANALYZEpara ter certeza de que o banco de dados não estava ficando muito inchado. Fazer isso em um banco de dados de produção me permitiu descobrir que isso não era uma boa ideia, porque eu poderia bloquear a tabela por um longo período de tempo. Então, eu cancelei o processo, talvez tentei apenas VACUUM(não completo) ou deixe AUTOVACUUMfazer mais tarde o que puder fazer.

A questão é: se eu parar um VACUUM ou AUTOVACUUM "no meio do caminho", todo o processamento já feito é perdido?

Por exemplo, se VACUUMjá encontrei 1 M de linhas mortas e eu paro, todas essas informações são perdidas? O VACUUM funciona de maneira totalmente transacional ("tudo ou nada", como um bom número de processos do PostgreSQL)?

Se VACUUM puder ser interrompido com segurança sem que todo o trabalho seja perdido, existe alguma maneira de fazer o vacuumtrabalho de forma incremental? [Trabalhe por 100 ms, pare, espere 10 ms para permitir o não bloqueio do resto do mundo... e assim por diante]. Eu sei que você pode fazer parte disso ajustando os parâmetros do autovacuum, mas estou pensando em poder controlar isso programaticamente, poder fazê-lo em determinados momentos / sob certas condições.

NOTA: Parar / cancelar / matar o processo significa neste contexto:

• Se estiver usando o pgAdmin, pressione o botão "Cancelar consulta".
• Se estiver trabalhando programaticamente, chame pg_cancel_backend().

Suponho que ambos sejam equivalentes. Eu não usei nenhum comando kill no nível do shell/sistema.