All perguntas(dba)

Atualmente, estou indexando coluna por coluna com o seguinte trecho de código:

DECLARE
    already_exists  EXCEPTION;
    columns_indexed EXCEPTION;
    PRAGMA EXCEPTION_INIT ( already_exists, -955 );
    PRAGMA EXCEPTION_INIT (columns_indexed, -1408);

BEGIN
   EXECUTE IMMEDIATE 'Create Index TABLE_A_COLUMN_A on TABLE_A(COLUMN_A)';
EXCEPTION
   WHEN already_exists or columns_indexed
   THEN
      NULL;
END;

É possível substituir COLUMN_Aneste código

a) com uma referência de lista e iterar por ela dinamicamente?

declare @myList varchar(100)
set @myList = 'COLUMN_A,COLUMN_B,COLUMN_C'

b) e certifique-se de que o loop continue em loop mesmo quando encontrar um problema com uma coluna? Em outras palavras, nem todo o loop deverá falhar se houver um problema com uma das colunas

Alguns trabalhos do SQL Server Agent falharam recentemente com erros de conflito. Queria ficar de olho no problema e criei um alerta de monitoramento no SSMS. No entanto, o evento nunca dispara.. o que parece errado.

Propriedades de alerta:

Alerta com script:

EXEC msdb.dbo.sp_add_alert @name=N'Deadlock(s) detected . . .', 
    @message_id=0, 
    @severity=0, 
    @enabled=1, 
    @delay_between_responses=720, 
    @include_event_description_in=1, 
    @category_name=N'[Uncategorized]', 
    @performance_condition=N'Locks|Number of Deadlocks/sec|Database|>|0', 
    @job_id=N'00000000-0000-0000-0000-000000000000'
GO
EXEC msdb.dbo.sp_update_notification @alert_name=N'Deadlock(s) detected . . .', 
    @operator_name=N'Watchdog', @notification_method = 1

O que está a faltar? Ou há uma maneira melhor de fazer isto?

Eu tenho a configuração de replicação mostrada na imagem. Tudo se replica para todos os lugares. Uma das tabelas mantém dados da sessão que possuem linhas que devem ser excluídas devido à expiração. Criei um evento que verifica sessões expiradas uma vez por dia e as exclui:

DELETE FROM session 
WHERE expiration < (UNIX_TIMESTAMP() - 7200);

Minhas perguntas são estas:

1. Isso levará a uma condição instável em que cada um dos bancos de dados estará (quase) executando simultaneamente o evento e ao mesmo tempo tentando replicar as atualizações?
2. Em caso afirmativo, um evento pode ser restrito a uma única instância de banco de dados com SQL ou por algum outro meio?
3. Um evento é a ferramenta adequada para este trabalho?

Observe que o Site A e o Site B estão fisicamente separados (costa leste e oeste dos EUA), portanto há atraso na rede.

Editar: Este é o MySQL 8.0.36

Eu apreciaria alguns conselhos, por favor? Tivemos uma situação em que o log do TEMPDB estava cheio e não conseguimos nos conectar à réplica primária do nosso SQL 2019 AG do SSMS. No entanto, conseguimos nos conectar à réplica secundária, onde iniciamos um failover do primário para o secundário. O failover reverteu as transações em andamento no tempdb primário e, portanto, qualquer transação que causou o preenchimento do log foi revertida e o log foi liberado. Conseguimos então nos conectar a essa réplica e fazer um failback como principal.

Minha pergunta é: uma reinicialização dos serviços SQL em cada nó do servidor seria benéfica para evitar o preenchimento do templog novamente - ou seja, para recriar tempdbs vazios e limpos?

Tenho uma tabela que armazena o horário de início e término de alguns eventos. Quero pesquisar nesta tabela todos os eventos que ocorreram em um dia específico.

Aqui estão dados de exemplo:

Se eu quiser dados para 14/04, esta é a saída excetuada:

Aqui está minha consulta:

SELECT * FROM content WHERE
    DATE_FORMAT(dateBegin, '%d/%m/%Y') <= '14/04/2024'
AND
    DATE_FORMAT(dateEnd, '%d/%m/%Y') >= '14/04/2024'

Mas aqui está minha saída real:

Por que recebo uma linha do dia certo, mas de outro mês?

Fiz um Db Fiddle para mostrar esse problema.

Como posso consertar isso?

Nota: estou usando o MariaDB 10.11.4.

Estou pronto para arrancar meu cabelo. Fiz um script para fazer backup e restaurar banco de dados e grupo de arquivos que cria consultas como:

RESTORE DATABASE [dashdb_dev01_2024-04-11 143711] FROM DISK = 'E:\SQL2019_Data\Backup\dev01\20240410\1437\dashdb_dev01_2024-04-11 143711.bak' WITH REPLACE, RECOVERY, MOVE [dashdb_dev01_2024-04-11 143711] TO 'E:\SQL2019_Data\Backup\OLD\dashdb_dev01_2024-04-11 143711.mdf'

E eu consegui:

Msg 102, Level 15, State 1, Server FRPARPLMA-DBDEV, Line 1
Incorrect syntax near 'dashdb_dev01_2024-04-11 143711'.

Eu uso [...]para escapar do nome do banco de dados, mas entendo pelo MSG 102 que é o 102º caractere (estou bem aqui?). Então é o 'E:\SQL2019_Data\Backup\dev01\20240410\1437\dashdb_dev01_2024-04-11 143711.bak'depois do FROM DISK.

Como posso escapar, penso eu, do espaço aqui?

(PG14.1) Abaixo está a saída de pg_log_backend_memory_contextsum PID para o qual pg_proctab()diz que rssé 216MB. Adicionei alguns pontos para facilitar a leitura de números grandes e anonimizei algumas coisas.

Não consigo entender:

• Como o TopMemoryContext tem apenas 5 MB, mas o total geral é de 100 MB?
• CacheMemoryContext tem 69 MB, mas 44 MB são gratuitos e 25 MB são usados. O que há nesses 25 MB? Não é exatamente isso que pg_log_backend_memory_contexts deveria me dizer (mas não diz)? Todas as entradas de ‘nível 2’ não chegam nem perto de 25 MB.
• Esses 44 MB gratuitos serão devolvidos ao sistema enquanto a sessão estiver ativa?
• Quando eu encerrar a sessão, ela liberará 216 MB de RAM (número pc_proctab) ou 100 MB (número pg_log_backend_memory_contexts) ou outro número?

logging memory contexts of PID 15744
level: 0; TopMemoryContext: 4.264.856 total in 104 blocks; 2.074.448 free (8510 chunks); 2190408 used
level: 1; pgstat TabStatusArray lookup hash table: 65536 total in 4 blocks; 4672 free (11 chunks); 60864 used
level: 1; RdsSuperUserCache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 3792 free (1 chunks); 4400 used: get_date_to_char(timestamp without time zone,character varying)
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 7032 free (5 chunks); 9352 used: get_number_to_char(numeric,character varying)
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 3824 free (3 chunks); 4368 used: get_to_number(character varying,character varying)
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 4504 free (1 chunks); 3688 used: <FUNCTION>
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 6616 free (4 chunks); 9768 used: <FUNCTION2>
level: 1; Sequence values: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; Btree proof lookup cache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 5752 free (5 chunks); 10632 used: get_date_interval(character varying,numeric)
level: 1; PL/pgSQL function: 32768 total in 3 blocks; 16608 free (5 chunks); 16160 used: <FUNCTION3>
level: 1; Operator lookup cache: 24576 total in 2 blocks; 10752 free (3 chunks); 13824 used
level: 1; RI compare cache: 16384 total in 2 blocks; 6656 free (3 chunks); 9728 used
level: 1; RI query cache: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; RI constraint cache: 40648 total in 2 blocks; 2616 free (0 chunks); 38032 used
level: 1; PL/pgSQL function: 8192 total in 1 blocks; 4592 free (1 chunks); 3600 used: get_systimestamp()
level: 1; Type information cache: 24376 total in 2 blocks; 2616 free (0 chunks); 21760 used
level: 1; PLpgSQL cast cache: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; PLpgSQL cast expressions: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; PL/pgSQL function: 16384 total in 2 blocks; 5992 free (4 chunks); 10392 used: <FUNCTION4>
level: 1; Function stat entries: 16384 total in 2 blocks; 6640 free (2 chunks); 9744 used
level: 1; CFuncHash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; Rendezvous variable hash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; PLpgSQL function hash: 24528 total in 2 blocks; 2616 free (0 chunks); 21912 used
level: 1; Prepared Queries: 16384 total in 2 blocks; 6656 free (3 chunks); 9728 used
level: 1; TableSpace cache: 8192 total in 1 blocks; 2088 free (0 chunks); 6104 used
level: 1; RowDescriptionContext: 57400 total in 3 blocks; 24272 free (7 chunks); 33128 used
level: 1; MessageContext: 8192 total in 1 blocks; 6888 free (1 chunks); 1304 used
level: 1; Operator class cache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; smgr relation table: 2.097.152 total in 9 blocks; 269224 free (33 chunks); 1827928 used
level: 1; TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used
level: 1; Portal hash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
level: 1; TopPortalContext: 8192 total in 1 blocks; 7928 free (2 chunks); 264 used
level: 1; Relcache by OID: 1.048.576 total in 8 blocks; 500672 free (16 chunks); 547904 used
level: 1; CacheMemoryContext: 69.478.096 total in 208 blocks; 44.098.912 free (106056 chunks); 25.379.184 used
level: 2; CachedPlanSource: 4096 total in 3 blocks; 1960 free (1 chunks); 2136 used: <INSERT>
level: 3; unnamed prepared statement: 16384 total in 2 blocks; 6824 free (1 chunks); 9560 used
level: 2; CachedPlan: 8.420.408 total in 15 blocks; 1409824 free (1 chunks); 7010584 used: <SELECT>
level: 2; index info: 2048 total in 2 blocks; 528 free (1 chunks); 1520 used: pg_toast_295195_index
level: 2; CachedPlan: 8192 total in 4 blocks; 2480 free (0 chunks); 5712 used: <DELETE>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: pg_sequence_seqrelid_index
level: 2; CachedPlan: 2048 total in 2 blocks; 280 free (0 chunks); 1768 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 16 free (0 chunks); 2032 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 160 free (1 chunks); 1888 used: <OTHER UNIQUE SQL>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: <OTHER UNIQUE SQL>
level: 2; index info: 3072 total in 2 blocks; 696 free (1 chunks); 2376 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; CachedExpression: 1024 total in 1 blocks; 488 free (0 chunks); 536 used
level: 2; CachedPlan: 2048 total in 2 blocks; 208 free (1 chunks); 1840 used: TO_NUMBER(p_input, p_fmt)
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 856 free (1 chunks); 2216 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 920 free (0 chunks); 1128 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3544 total in 3 blocks; 960 free (1 chunks); 2584 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4096 total in 3 blocks; 1912 free (3 chunks); 2184 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 840 free (0 chunks); 1208 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 504 free (0 chunks); 1544 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 856 free (1 chunks); 2216 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4024 total in 3 blocks; 816 free (1 chunks); 3208 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 7032 total in 4 blocks; 1928 free (2 chunks); 5104 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 4744 total in 3 blocks; 240 free (0 chunks); 4504 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 7032 total in 4 blocks; 1928 free (2 chunks); 5104 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3304 total in 3 blocks; 784 free (1 chunks); 2520 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3304 total in 3 blocks; 784 free (1 chunks); 2520 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 448 free (1 chunks); 1600 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 8192 total in 4 blocks; 3824 free (2 chunks); 4368 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 544 free (2 chunks); 1504 used: <OTHER UNIQUE INDEX NAME>
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: v_interval::INTERVAL
level: 2; CachedPlan: 2048 total in 2 blocks; 528 free (0 chunks); 1520 used: (v_interval IS NOT NULL)
level: 2; CachedPlan: 2048 total in 2 blocks; 144 free (1 chunks); 1904 used: v_interval := p_interval_length || ' second'
level: 2; CachedPlan: 2048 total in 2 blocks; 224 free (1 chunks); 1824 used: (p_interval = 'SECOND')
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1096 free (2 chunks); 1976 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1160 free (1 chunks); 1912 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 688 free (1 chunks); 1360 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1080 free (1 chunks); 1992 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 3072 total in 2 blocks; 1016 free (1 chunks); 2056 used: <OTHER UNIQUE INDEX NAME>
level: 2; index info: 2048 total in 2 blocks; 608 free (1 chunks); 1440 used: <OTHER UNIQUE INDEX NAME>
level: 1; 4141 more child contexts containing 12.748.648 total in 8713 blocks; 3.899.520 free (3559 chunks); 8.849.128 used
level: 1; WAL record construction: 49768 total in 2 blocks; 6360 free (0 chunks); 43408 used
level: 1; PrivateRefCount: 8192 total in 1 blocks; 1576 free (0 chunks); 6616 used
level: 1; MdSmgr: 524.288 total in 7 blocks; 412.640 free (8661 chunks); 111648 used
level: 1; LOCALLOCK hash: 1.048.576 total in 8 blocks; 215936 free (27 chunks); 832640 used
level: 1; Timezones: 104120 total in 2 blocks; 2616 free (0 chunks); 101504 used
level: 1; ErrorContext: 8192 total in 1 blocks; 7928 free (4 chunks); 264 used
Grand total: 100.635.144 bytes in 9342 blocks; 53.175.720 free (127010 chunks); 47459424 used

Hoje, depois de cerca de um mês, reiniciei meu servidor e agora recebo

Table 'ANY TABLE' doesn't exist in engine

em todas as tabelas do InnoDB que desejo abrir no phpMyAdmin. Minhas tabelas ISAM estão bem e funcionando. Vi que outras pessoas tiveram o mesmo problema depois de mover arquivos de um backup antigo para um diretório MySQL, mas não fiz isso.

Outra coisa estranha é que tenho um backup de uma máquina (é VMware), mas quando me recupero deles (tentei um backup de 2 dias atrás e um backup de 1 semana), recebo o mesmo erro, mas o banco de dados estava funcionando bem até hoje.

Portanto, não tenho backup SQL e apenas um backup de máquina VMware, mas mesmo um backup completo de máquina com 2 semanas não está resolvendo meu problema. Acho que é por causa de uma alteração que fiz há muito tempo, mas ela não apareceu até a reinicialização do servidor. Há algo que eu possa fazer para restaurar meu banco de dados e recuperá-los?

Estou usando o XAMPP no Linux. Não há erro ao executar o MariaDB. A recuperação forçada do InnoDB não ajudou nem 6. Mudei todas as pastas de dados + ib_logfiles + ibdata1 em um novo XAMPP, mas exatamente o mesmo erro aparece.

Me deparei com um formato inteiro para datas para as quais também sei a data, mas não sei como chegar a essa data no TSQL e também não sei como chegar ao número inteiro se tiver a data:

700444 -> 02/10/1918

731573 -> 24/12/2003

739479 -> 16/08/2025

Esses números de 6 dígitos serviriam como um contador para cada dia a partir de 0001-01-01, verifiquei isso obtendo o número de dias para um século a partir daquela data que é quase o ano 2000 e adicionando isso a 1900:

select DATEADD(dd,731573/20,'19000101')

Fora:

2000-02-24 00:00:00.000

Mas não consigo correr select DATEADD(dd,731573/20,'10000101'), o que gera:

A conversão de um tipo de dados varchar em um tipo de dados datetime resultou em um valor fora do intervalo.

O Microsoft Learn diz que o TSQL permite datas apenas a partir de 1753-01-01, veja datetime (Transact-SQL) Microsoft Learn , assim:

select DATEADD(dd,731573/20,'17530101')

Fora:

1853-02-24 00:00:00.000

Porém, não posso adicionar 731573 ao ano 1. Então descobri Qual é o significado de 01/01/1753 no SQL Server? :

--(como dito em uma das respostas e em Por que você deve sempre escrever "varchar" com o comprimento entre colchetes atrás dele? Muitas vezes, você obtém o resultado certo sem fazer isso - DBA SE , pegue varchar(length)em vez de apenas varchar)--

SELECIONE CONVERT(VARCHAR, DATEADD(DAY,-731572,CAST('2003-12-24' AS DATETIME2)),100)

SELECT CONVERT(VARCHAR(30), DATEADD(DAY,-731572,CAST('2003-12-24' AS DATETIME2)),100)

Fora:

Jan  1 0001 12:00AM

Para que isso seja comprovado, o número são os dias a partir do primeiro dia do ano 0001. Agora me pergunto se consigo chegar lá sem formatar a coluna datetime como datetime2. Minhas datas são todas apenas nos séculos 20 e 21, então não preciso do arquivo datetime2. Recebo os dados como data e hora e tento evitar uma conversão de tipo.

Como posso converter esse número inteiro em setecentos mil como o contador dos dias do ano 1 até uma data e como posso voltar da data para esse número inteiro sem converter a data em datetime2?

Eu tenho uma tabela Activity_log que preciso obter uma saída básica de quantos usuários distintos efetuaram login naquele dia e resumi-los dia a dia. A tabela registra todas as ações de um usuário e terá diversas entradas por dia para cada usuário. Aqui está a mesa -

Isso é o que eu tenho até agora -

selecione DISTINCT CAST (test.activitytime AS data) Data, nome de usuário de [dbo].[activity_log] como teste
onde test.activitytime entre '2024-03-01' e '2024-03-08'
ordene por data

Aqui está a saída para isso -

Preciso que ele seja exibido todos os dias uma vez e some o total de usuários distintos por dia (não importa se eles fizeram login ontem também), apenas o total de usuários distintos por dia. Estou perdido sobre para onde ir a partir daqui

ou seja

2024-03-01 24

02/03/2024 39

2024-03-03 26