"Bloco anônimo" é um termo da Oracle. Mas falando da coisa para sql server
Declare
....
Begin
begin trans
. . .
commit
End
Se eu enviar esse SQL de forma parametrizada para o servidor via ADO.NET, ele será armazenado em cache e reutilizado ou será recompilado todas as vezes?
Mais uma pergunta da minha descoberta das ótimas novas EXPLAINopções do PostgreSQL. Este se concentra na BUFFERSopção.
Aqui está EXPLICAR :
EXPLAIN (ANALYZE, BUFFERS) SELECT event_time FROM ui_events_v2 WHERE page ~ 'foo' LIMIT 1;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..1539.68 rows=1 width=8) (actual time=0.858..0.858 rows=1 loops=1)
Buffers: shared read=10
I/O Timings: read=0.735
-> Seq Scan on ui_events_v2 (cost=0.00..3313394.58 rows=2152 width=8) (actual time=0.857..0.857 rows=1 loops=1)
Filter: (page ~ 'foo'::text)
Rows Removed by Filter: 112
Buffers: shared read=10
I/O Timings: read=0.735
Planning Time: 6.455 ms
Execution Time: 0.877 ms
É bastante rápido - e essa consulta é muito lenta em uma inicialização a frio. Esta é uma tabela de 30 milhões de linhas e sete linhas pagecontêm substring foo. A primeira linha que corresponde a esta consulta parece mostrar 604 mil páginas, o que seria ~20% das ~3 milhões de páginas mencionadas em pg_class:
SELECT min(ctid) FROM ui_events_v2 WHERE page ~ 'foo';
min
-------------
(604435,10)
Minha suposição era que, mesmo que cada página desta tabela estivesse no cache do PostgreSQL ou do sistema operacional, ela ainda precisaria percorrer uma lista linear de páginas para uma varredura sequencial. A seção Buffers: shared read=10e o 0.877 mstempo de execução me sugerem que de alguma forma está "pegando de onde parou" e começando em páginas que estão longe do início. Eu pensei que ele se movia através de IDs de página e espiava em um cache tentando cada página enquanto se movia, mas talvez comece a partir do próprio cache? Se for esse o caso, como ele descobre as páginas não armazenadas em cache?
Eu sei que não é garantido que as linhas sejam encontradas em nenhuma ordem específica, mas imaginei que, dentro da mesma estratégia de consulta, o caminho seguido seria relativamente semelhante.
Até onde eu sei, o SQL Server gerencia automaticamente o tamanho dos componentes do buffer pool. Gostaria de saber se é possível definir tamanho pré-definido para cache de plano e cache de dados?
estamos usando MariaDB 10.2 com plugin Galera. O cluster consiste em 4 nós - 3 são consultas complexas de serviço ocupado e 1 é mais para um backup.
Recentemente nos deparamos com o ProxySQL e isso nos parece muito interessante em termos de dividir consultas de inserção em um servidor e selecionar dados de outros. Esperamos evitar deadlocks e problemas de autoincremento durante alta atividade.
Mas um de nossos desenvolvedores descobriu um atraso - ao usar o ProxySQL ele tenta inserir um registro simples e fazer uma seleção instantânea desse registro. Em geral, a cada segundo ou terceiro tal solicitação de seleção falha devido à latência. Se ele adicionar um pequeno atraso de 0,01s - ele nunca falhará, pois todos os nós da galera são capazes de sincronizar dentro desse tempo.
Agora a questão é - é possível armazenar em cache os dados inseridos com o ProxySQL, para que a "seleção" instantânea seja retornada do cache, pelo menos nos primeiros 0,01 segundos.
Ou existem outras formas ou sugestões neste cenário?
Obrigada. :)
Estou tentando descobrir se a relação do Postgres e o cache do catálogo são por conexão ou por servidor? Eu descobri que os caches do plano são por conexão. Faz sentido que o cache exista enquanto o servidor estiver em execução, mas não consigo encontrar nenhuma documentação sobre ele.
Se você observar algo como https://redis.io/commands#list , verá que os tipos que o Redis armazena e suporta são totalmente mutáveis, atomicamente, na memória do armazenamento de dados.
Isso não faz muito sentido, já que o Redis existe principalmente como um cache para acelerar aplicativos que têm um banco de dados separado do Redis e usam o Redis apenas como um local para ler os valores.
O que estou perdendo aqui? Por que ter mutabilidade em valores diretamente no Redis quando isso não se encaixa em um modelo de cache?
Estou tentando entender os internos do MySQL. Eu sei que o gerenciamento de buffer pool do MySQL tem uma lista de páginas antigas/jovens como mostra aqui. E eu sei sobre a descarga de páginas sujas antigas, como explicado aqui e como personalizá-lo aqui. Também estou ciente de que o MySQL usa um algoritmo LRU para remoção de página como aqui.
No entanto, existe um daemon/thread do conjunto de buffers que despeja páginas somente leitura (não páginas sujas) que foram trazidas para o conjunto de buffers por, digamos, uma instrução select? Existem maneiras de personalizá-lo (por exemplo, quando eu passar 95% da capacidade do bufferpool, começar a despejar páginas lidas ou liberar páginas sujas). Em outras palavras, quais gatilhos no algoritmo LRU despejam páginas do buffer pool (por exemplo, tempo em que uma página está no buffer pool, porcentagem de buffer pool preenchido, necessidade de despejar páginas para que novas páginas sejam carregadas), isso é ajustável?
O SQL Server armazena em cache o resultado de uma coluna computada não persistente para que possa ser reutilizada sem incorrer em custos de recálculo?
Contexto Adicional Sempre dei o conselho de que, se estiver usando colunas computadas, você deve usar a opção PERSISTED, a menos que esteja esperando uma frequência de inserção/atualização maior do que a frequência de leitura, ou se precisar de melhor desempenho em inserções/atualizações do que as leituras de os dados (ou seja, uma vez que o custo do cálculo deve ser incorrido em um ou outro, então a decisão é realmente onde você quer pagar esse custo).
Há também a consideração do armazenamento adicional para os dados computados, mas normalmente isso é bastante insignificante e barato, portanto, não é muito importante.
No entanto, eu queria verificar se meu conselho é totalmente preciso, já que o SQL pode ser mais inteligente ... consultas. O SQL pode ter um carimbo de data/hora no valor armazenado em cache e outro nos dados do registro subjacente para dizer se esse registro foi alterado desde que o valor calculado foi calculado para determinar se o valor armazenado em cache ainda é válido.
Existe algo assim em vigor / depende dos recursos disponíveis (por exemplo, memória) ou outros fatores (por exemplo, o valor em cache tem um TTL além do tempo de vida do processo)? Eu nunca li nada sugerindo que isso existe, mas ficaria surpreso se não houvesse alguma otimização acontecendo nos bastidores.
Ao definir a statistics ioopção ON, vejo este resultado
as leituras físicas são 0 e as leituras antecipadas são 276, o que significa que 276 páginas dessa tabela que estão na unidade de disco estavam no cache de dados, mas o número total de leituras do cache de dados é 794, conforme indicado nas leituras lógicas. Então, o que é mantido no cache de dados além das páginas da tabela da unidade de disco?
Obrigado.
No Dynamics AX existe um mecanismo de cache onde as tabelas podem ser configuradas para serem carregadas na memória e armazenadas em cache. Esse cache é limitado a uma certa quantidade de KB para evitar problemas de memória. A configuração de que estou falando é chamada entiretablecachee carrega toda a tabela na memória assim que um único registro é solicitado.
Até recentemente contamos com alguns scripts para verificar o tamanho das tabelas que possuem essa configuração para ver se o tamanho da tabela está acima desse limite.
Agora, no entanto, a compactação entra em ação e coisas como sp_spaceused ou sys.allocation_units parecem relatar o espaço realmente usado pelos dados compactados.
Obviamente, o servidor de aplicativos está trabalhando com dados não compactados, portanto, o tamanho dos dados no disco no SQL Server é irrelevante. Eu preciso do tamanho real que os dados descompactados terão.
Conheço sp_estimate_data_compression_savings , mas como o nome diz, isso é apenas uma estimativa.
Eu preferiria ter o tamanho o mais correto possível.
A única maneira que eu conseguia pensar era algum SQL dinâmico complicado criando tabelas não compactadas com a mesma estrutura das tabelas compactadas, inserindo os dados compactados nessa tabela sombra e, em seguida, verificando o tamanho dessa tabela sombra.
Desnecessário dizer que isso é um pouco tedioso e demora um pouco para ser executado em um banco de dados de várias centenas de GB.
O Powershell pode ser uma opção, mas eu não gostaria de iterar em todas as tabelas para executar um select *nelas para verificar o tamanho no script, pois isso apenas inundaria o cache e provavelmente levaria muito tempo também.
Em suma, preciso de uma maneira de obter o tamanho de cada tabela, pois ela será descompactada e com fragmentação fora da equação conforme apresentada ao aplicativo, se for possível. Estou aberto a diferentes abordagens, T-SQL é o preferido, mas não me oponho ao Powershell ou outras abordagens criativas.
Suponha que o buffer no aplicativo seja o tamanho dos dados. Um bigint é sempre do tamanho de um bigint e um tipo de dados de caractere é de 2 bytes por caractere (unicode). Os dados BLOB também assumem o tamanho dos dados, um enum é basicamente um int e os dados numéricos são numéricos (38,12), datetime é o tamanho de um datetime. Além disso, não há NULLvalores, eles são armazenados como uma string vazia 1900-01-01ou zero.
Não há documentação sobre como isso é implementado, mas as suposições são baseadas em alguns testes e nos scripts usados pelos PFEs e pela equipe de suporte (que também ignoram a compactação aparentemente, já que a verificação é construída no aplicativo e o aplicativo não pode dizer se os dados subjacentes estiverem compactados) que também verificam os tamanhos das tabelas. Este link, por exemplo, afirma:
Evite usar caches de tabela inteira para tabelas grandes (no AX 2009 com mais de 128 KB ou 16 páginas, no AX 2012 com a configuração do aplicativo 'tamanho do cache de tabela inteira' [padrão: 32 KB ou 4 páginas]) – mude para o cache de registro.