Gostaria de selecionar dados do último período de 15 minutos, por exemplo:
às 12h02 quero linhas das 11h45 às 12h
às 12h09 ainda quero linhas das 11h45 às 12h
às 12h18 quero linhas das 12h às 12h15
Os dados são armazenados no formato datetime2 e estou usando a edição padrão 2019. Qualquer ajuda será apreciada para começar. A especificação pode mudar mais tarde (por exemplo, períodos de 10 minutos em vez de 15 minutos), mas espero poder resolver isso sozinho.
Obrigado
Eu tenho um spid obstinado que não consigo matar e está impedindo que o log de transações do meu tempdb seja truncado
foi assim que encontrei esse aranha desonesto:
if object_id('tempdb..#OpenTranStatus','U') is not null
drop table #OpenTranStatus
CREATE TABLE #OpenTranStatus (
ActiveTransaction varchar(25),
Details sql_variant
);
-- Execute the command, putting the results in the table.
INSERT INTO #OpenTranStatus
EXEC ('DBCC OPENTRAN (sqlwatch) with tableresults')
SELECT * FROM #OpenTranStatus
esta é a consulta que ele está executando (ou mantendo):
select d.database_id , sd.sqlwatch_database_id, sd.sql_instance
into #d
from dbo.vw_sqlwatch_sys_databases d
inner join [dbo].[sqlwatch_meta_database] sd
on sd.[database_name] = d.[name] collate database_default
and sd.[database_create_date] = case when d.name = 'tempdb' then '1970-01-01 00:00:00.000' else d.[create_date] end
and sd.sql_instance = @sql_instance
left join [dbo].[sqlwatch_config_exclude_database] ed
on d.[name] like ed.database_name_pattern collate database_default
and ed.snapshot_type_id = @snapshot_type_id
where ed.snapshot_type_id is null
option (keep plan)
está funcionando há mais de 60 horas:
Já foi morto.
então as coisas que tentei fazer:
alter database sqlwatch set single_user with rollback immediate
mas não funcionou
kill 54 with statusonly
SPID 54: reversão de transação em andamento. Conclusão estimada da reversão: 0%. Tempo restante estimado: 0 segundos.
pergunta:
como posso parar o spid54?
Tenho uma tabela com estrutura em árvore (definida por hierarchyidcoluna) e quero selecionar todos os descendentes de um determinado registro. Para isso, estou usando hiearchyid.IsDescendantOf()o método.
Eu esperava que, como não estou fazendo comparações simples, mas estou executando operações (neste caso, estou chamando o IsDescendantOf()método), obterei um plano de execução terrível com varreduras de índice e outros enfeites.
Mesmo assim, o SQL Server o otimizou para uma pequena busca de índice.
Estou intrigado por que e como.
A chamada de métodos em tipos CLR geralmente é otimizada? Presumi que o SQL Server vê os tipos CLR como uma caixa preta opaca e, portanto, não pode fazer sua mágica funcionar nele. (Uma vez que também não é possível fazer isso em funções SQL nativas.)
Ou isso é apenas para este método específico? (Como os hieararchyidvalores são ordenados em profundidade, eu poderia obter resultados semelhantes apenas fazendo comparações.)
Demonstração:
CREATE TABLE dbo.HierarchyExample (
Id INT PRIMARY KEY,
Hieararchy HIERARCHYID NOT NULL
);
INSERT INTO dbo.HierarchyExample(Id, Hieararchy)
VALUES
(1, hierarchyid::Parse('/1/')),
(2, hierarchyid::Parse('/1/1/')),
(3, hierarchyid::Parse('/1/2/')),
(4, hierarchyid::Parse('/1/3/')),
(5, hierarchyid::Parse('/1/3/1/')),
(6, hierarchyid::Parse('/1/3/2/')),
(7, hierarchyid::Parse('/1/3/3/')),
(8, hierarchyid::Parse('/1/4/')),
(9, hierarchyid::Parse('/1/4/1/')),
(10, hierarchyid::Parse('/1/4/2/'));
CREATE INDEX IX_HierarchyExample_Hierarchy
ON dbo.HierarchyExample (Hieararchy);
SELECT descendant.*
FROM HierarchyExample ancestor
INNER JOIN HierarchyExample descendant
ON descendant.Hieararchy.IsDescendantOf(ancestor.Hieararchy) = 1
WHERE ancestor.Id = 1
DROP TABLE IF EXISTS dbo.HierarchyExample;
Tendo o seguinte trecho de tabela:
CREATE TABLE `some_table` (
`exp_col_1` TINYINT(1) NOT NULL DEFAULT '0',
`mark_col_1_as_exported` TINYINT(1) DEFAULT '0',
`exp_col_2` TINYINT(1) DEFAULT '0',
`mark_col_2_as_exported` TINYINT(1) DEFAULT '0',
);
existe uma maneira de escrever uma consulta para:
mark_col_1_as_exportedondeexp_col_1=1mark_col_2_as_exportedondeexp_col_2=1Eu sei que posso escrever um UPDATE para cada um deles mas isso é apenas um trecho, estamos falando aqui de cerca de 20 colunas a serem atualizadas
Recentemente, tive uma falha no mariadb que deu início a um pesadelo. Quando restaurei dumps, às vezes o daemon travava durante inserções em massa. Isso aconteceu apenas nas poucas tabelas "grandes" do innodb (tenho muitos bancos de dados pequenos que realmente não contêm muitos dados e a maioria dos outros possui uma quantidade significativa apenas em algumas tabelas). O banco de dados geralmente se recuperava eventualmente (às vezes depois de horas), mas às vezes travava. Restaurei o banco de dados em uma máquina diferente sem problemas em questão de minutos e depois movi o diretório de dados na máquina de produção. A única diferença séria entre os dois é que a máquina de sucesso não é uma VM e sim um armazenamento SSD esportivo.
Desde então, os problemas descritos ainda acontecem, em momentos aleatórios, sempre ao acessar aquelas tabelas grandes. Geralmente terei várias consultas congeladas, mas apenas uma às vezes é suficiente para acionar o comportamento.
O que acho realmente difícil de acreditar é o fato de que o iotop relata um thread mariadb gravando gigabytes por segundo , de forma constante, durante todo o tempo em que a consulta trava. Isso é fisicamente impossível, já que o desempenho dos discos não chega nem perto desses números. Também vasculhei a internet para encontrar o que pude sobre como otimizar configurações que até alguns dias atrás pareciam perfeitamente adequadas para o meu ambiente, ajustei algumas variáveis, mas nada importante, também os padrões na máquina "importação bem-sucedida" não eram muito diferentes começar com.
O problema é semelhante a https://jira.mariadb.org/browse/MDEV-30884 , no entanto, isso foi supostamente corrigido porque estou usando o 10.6.14 (também testei o 10.6.15) no Gentoo.
Estou perplexo, o que poderia estar causando isso? O armazenamento mecânico do HDD pode de alguma forma justificar o que está acontecendo?
Estou movendo um banco de dados SQL Server para um servidor separado do aplicativo que o utiliza (atualmente o aplicativo e o SQL estão no mesmo servidor).
A nova instância foi configurada para que os arquivos de dados ( .mdf) e de log ( .ldf) padrão sejam armazenados em unidades separadas, de acordo com o que entendo ser a prática recomendada geral.
Passei pelo processo de mover os arquivos de banco de dados do sistema não mestre (temp, modelo, etc.) para esses locais, deixando o mestre por último porque ele usa um processo diferente. Veja este link para as instruções que usei: https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-system-databases?view=sql-server-ver16
Para o banco de dados mestre, as instruções dizem que após movê-lo, você deve atualizar o SQLDataRootvalor no registro para apontar para a localização dos "arquivos do banco de dados mestre", mas como os arquivos de dados e log agora estão em pastas separadas, eu estava' não tenho certeza de qual local especificar. A partir daí, me perguntei de forma mais ampla se deveria separá-los ou se eles deveriam permanecer sempre juntos, e apenas novos bancos de dados teriam seus dados e arquivos de log movidos para unidades separadas.
Ainda não tentei mover o banco de dados mestre, devido à dúvida que tenho sobre como configurar o valor do registro e se algum dos arquivos do banco de dados do sistema deve ser separado ou mantido junto.
Estou restaurando um banco de dados, esse banco de dados é muito grande e possui 6 arquivos de backup (o que significa que o backup é dividido em 6 arquivos menores). Posso ver uma indicação disso usando apenas o rótulo de restauração
MediaFamilyId uniqueidentifier Número de identificação exclusivo da família de mídia.
MediaSequenceNumber int Número de sequência desta mídia na família de mídia.
aqui estão os comandos de restauração:
restore filelistonly
FROM DISK = '\\MY_BACKUP_SERVER\SQLBackups\MY_SERVER\MY_DATABASE\FULL\MY_SERVER_MY_DATABASE_FULL_20231215_180002_6.bak'
restore labelonly
FROM DISK = '\\MY_BACKUP_SERVER\SQLBackups\MY_SERVER\MY_DATABASE\FULL\MY_SERVER_MY_DATABASE_FULL_20231215_180002_6.bak'
restore headeronly
FROM DISK = '\\MY_BACKUP_SERVER\SQLBackups\MY_SERVER\MY_DATABASE\FULL\MY_SERVER_MY_DATABASE_FULL_20231215_180002_6.bak'
Minha pergunta é: como posso encontrar (neste caso 6) arquivos dentro do msdb?
Basicamente, uma consulta para obter esses 6 - o último backup completo - restaura esses (6) arquivos.
Eu tenho um cluster Cassandra composto por 21 nós (cada nó tem volume de dados Cassandra de 4 TB) e preciso substituir os nós (migração do Ubuntu 18.04 para 22.04)
Gostaria de saber se é possível reanexar o volume de dados da instância existente a uma nova sem consequências negativas? Eu estava pensando em seguir o plano:
Há algum risco em fazer isso, a única coisa que será alterada é o endereço IP privado do nó.
Posso executar algo assim no Postgresql, ou seja, executar CASCADE DELETEpara apenas uma instrução?
DELETE CASCADE FROM foo WHERE bar = 'baz';
Meu objetivo é excluir não apenas os registros selecionados de table foo, mas todos os registros em todas as tabelas onde foo.idcolumn é usado como chave estrangeira, sem adicionar a restrição para toda a tabela foo: ON DELETE CASCADE.
Relacionado:
ALTERa tabela inteira e afeta todas as DELETEinstruções. Eu quero fazer algo assim, mas por declaração .ON DELETE CASCADEsão discutidos nas respostas destas perguntas e respostas.
Estou executando o Postgres16 no servidor Windows. Comece a pesquisar no pg_basebackup - quando executo o seguinte comando, pg_basebackup.exe -h SERVERNAME -U postgres -p 5432 -D Z:\PostgreSQL\16\backups\ -Fp -Xs -P -R --checkpoint=fast --max-rate=1024M
recebo o seguinte erro:
pg_basebackup: erro: conexão com o servidor na porta 5432 "servername" falhou: FATAL: nenhuma entrada pg_hba.conf para conexão de replicação do host, usuário "postgres", sem criptografia
Acho que é porque adicionei as conexões SSPI .
Eu tenho as seguintes entradas antes do sspi, mas ainda recebo erros
host all all 0.0.0.0/0 scram-sha-256
host all all 127.0.0.1/32 scram-sha-256
host all all ::0/0 sspi map=sspi
Como faço para corrigir o pg_hba para que eu possa usar o sspi para determinados nomes de usuário que possam permitir conexões para logins locais (muito parecido com o modo misto no MSSQL)?
Obrigado