"Fundamentos de Sistemas de Banco de Dados", 3ª ed. por Elmasri e Navathe, página 136 diz:
"Podemos ordenar fisicamente os registros de um arquivo em disco com base nos valores de um de seus campos [...]"
Como essa "ordenação física" poderia ser aplicada, especialmente no que diz respeito à fragmentação? A maioria dos bancos de dados usa chamadas de sistema para armazenar seus dados no sistema de arquivos do sistema operacional, apenas muito poucos são capazes de fazer E/S bruta.
Eu entendo a diferença básica entre um tipo CHARde VARCHARdados que CHARocupa um comprimento fixo, enquanto VARCHARocupa espaço com base no conteúdo que está sendo armazenado.
Mas se VARCHARé tão eficiente em lidar com a gestão do espaço dinamicamente com base no conteúdo que está sendo armazenado, por que bancos de dados tem suporte para CHARdatatype, todos os CHAR(n)campos podem ser VARCHAR(n)campos, certo?
Eu tenho um banco de dados de 2 TB e o Data Drive está cheio. Minha equipe de rede não pode expandir a unidade nem fornecer outra unidade para que o arquivo de dados secundário possa ser apontado para ela. Minha pergunta é a unidade secundária pode ser apontada para um compartilhamento de rede.
Além de preencher acidentalmente toda a unidade C:\ com dados, existem outras considerações para usar a unidade do sistema operacional para arquivos de dados? A maioria das respostas é simplesmente "não faça isso", mas gostaria de saber quaisquer razões técnicas.
Estou em uma caixa de desenvolvimento e com prazer troco o risco por largura de banda de E/S extra. Estou refatorando um conjunto de dados muito grande, que gera arquivos de log de 10 a 20 GB (simples) e uma tonelada de atividade tempdb. Estou movendo a fonte, tabelas somente leitura para SSDs sata. Eu gostaria de dar aos dados refatorados, dados tempdb e arquivos de log seu próprio NVMe, mas isso significa que um deles compartilharia C: com o sistema operacional.
de acordo com este blog:
Os manuais online do SQL Server definem IO_COMPLETION como “Ocorre enquanto aguarda a conclusão das operações de E/S. Esse tipo de espera geralmente representa E/Ss de página sem dados . As esperas de conclusão de E/S da página de dados aparecem como PAGEIOLATCH_ waits ”*
O que significam IOs de página sem dados? ou podemos colocar a questão de outra forma: O que realmente significa “...aguardando a conclusão das operações de E/S”
?
Uma abordagem possível para otimizar as consultas de pesquisa é (a) armazenar os registros que retêm dados que correspondem a diferentes relações/tabelas em (b) o mesmo arquivo → nas mesmas páginas. Dessa forma, uma junção pode ser executada muito mais rapidamente.
Eu pesquisei "co-clustering" e surpreendentemente poucos resultados apareceram. Não encontrei nada no MySQL, por exemplo. Há alguma indicação de que a Oracle o ofereceu há 10 anos. O co-clustering ainda é uma opção válida para otimização?
Por exemplo, você tem duas relações/tabelas:
Employee (id, name, age, did) Department (did, location)Uma consulta típica para a qual você otimiza talvez seja algo assim:
SELECT E.name,
E.age
FROM Employee E,
Department D
WHERE E.age = 25
AND E.did = D.did;
Se você tinha 1.000.000 de funcionários e todos eles têm entre 25 e 27, o melhor método de junção é provavelmente a junção por mesclagem ou junção por hash - ambos exigem várias verificações.
Agora, se você armazena tuplas/linhas de várias relações/tabelas na mesma página, você pode usar uma estrutura física que armazena um departamento com um determinado didjuntamente com funcionários com o mesmo did. Observe que essa junção requer muito menos E/S.
Estou tentando entender o churn de cache causado por instruções SQL que estão fazendo algumas varreduras de tabela.
Assumindo caches LRU, se algo está fazendo 400K E/S lógicas, quanta memória é transmitida (tamanho do bloco de E/S * E/S lógicos).
Além disso, estou tentando entender como obter o relatório sobre as principais instruções SQL de E/S lógica e obter a E/S física que elas incorreram.
Diante disso, minhas dúvidas são:
Instalamos unidades SSD dedicadas para TempDB
O TempDB se beneficia do tamanho da unidade de 64 Kb ou pode ficar com o padrão de 4 Kb?
Não podemos alterar o tamanho da unidade de alocação para esses volumes neste momento. Portanto, se alterarmos a unidade SSD TempDB para 64 Kb e os volumes de dados/log permanecerem em 4 Kb, isso causará algum problema para o SQL Server?
Minha intuição é NULLque vai ocupar menos espaço do que {}quando usado como valor padrão de uma ARRAY[]coluna no PostgreSQL.
Estou correcto?
Estou usando o Alibaba Cloud - ECS e tenho o Storage Bucket - Object Storage Service (OSS).
A estrutura de armazenamento de arquivos é como
oss:/bucket/abc/xyz/123.jpg/
Minha pergunta é
Posso mover ou modificar os objetos no OSS?