Tenho o SQL Server 2022 com Always On Availability Group em dois servidores.
SRVSQL01 - Réplica Primária
SRVSQL02 - Réplica Secundária
No SRVSQL01, o backup Full é executado normalmente. Quando o SRVSQL01 se torna uma réplica Secondary, a seguinte mensagem de erro aparece.
"Este comando BACKUP ou RESTORE não é suportado em um espelho de banco de dados ou réplica secundária."
O que devo fazer para que o backup do banco de dados continue sendo executado mesmo quando ocorrer failover?
Obrigado.
Suponha que meu servidor tenha um trabalho que às vezes reconstrói índices com base em fatores que não controlo (por exemplo, fragmentação). Suponha também que tenho certeza de que um dia ele reconstruirá um índice que estou interessado em alterar. Existe alguma maneira de instruir o SQL Server que eu quero alterar o WITHíndice de um índice em sua próxima reconstrução, sem reconstruí-lo agora?
Por exemplo, suponha que ele PK_HugeTableesteja definido para preencher o fator 25. Na próxima reconstrução, quero defini-lo como 100. Se eu não quiser reconstruir o índice agora, o que devo fazer?
ALTER INDEX [...] SETfunciona para algumas opções, mas não para o fator de preenchimento.
Estou tentando ler um arquivo csv no meu banco de dados SQL, mas não consigo fazer isso por causa de problemas de segurança com o secure_file_priv. Li muitas postagens que me disseram para editar my.cnf para permitir que uma pasta seja acessada pelo SQL. Atualmente, meu my.cnf se parece com isso:
[mysqld]
secure_file_priv = /private/var/lib/mysql-files
pid-file = /usr/local/mysql/data/mysqld.local.pid
Mas, quando eu corro
SHOW VARIABLES LIKE 'secure_file_priv';
Eu ainda recebo um valor NULL. Eu também reinstalei o mysql e reiniciei meu banco de dados muitas vezes. Enquanto minhas alterações no arquivo my.cnf são salvas, não há efeito na saída.
Também fiquei pensando se isso tinha algo a ver com não especificar um arquivo de configuração, mas quando eu especificava um caminho para meu arquivo my.cnf, meu servidor parava automaticamente depois que eu o iniciava.
EDIT: Adicionando conteúdo do log de erros aqui sudo tail -f /usr/local/mysql/data/mysqld.local.err:
2024-09-21T20:38:24.709702Z 0 [System] [MY-015016] [Server] MySQL Server - end.
2024-09-21T20:38:29.338249Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2024-09-21T20:38:29.487803Z 0 [System] [MY-010116] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.4.2) starting as process 3726
2024-09-21T20:38:29.490033Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
2024-09-21T20:38:29.495667Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-09-21T20:38:29.575501Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-09-21T20:38:29.700945Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-09-21T20:38:29.700966Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-09-21T20:38:29.712909Z 0 [System] [MY-010931] [Server] /usr/local/mysql/bin/mysqld: ready for connections. Version: '8.4.2' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server - GPL.
2024-09-21T20:38:29.712908Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /tmp/mysqlx.sock
^C
% sudo tail -f /usr/local/mysql/data/mysqld.local.err
2024-09-21T20:38:24.709702Z 0 [System] [MY-015016] [Server] MySQL Server - end.
2024-09-21T20:38:29.338249Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2024-09-21T20:38:29.487803Z 0 [System] [MY-010116] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.4.2) starting as process 3726
2024-09-21T20:38:29.490033Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
2024-09-21T20:38:29.495667Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-09-21T20:38:29.575501Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-09-21T20:38:29.700945Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-09-21T20:38:29.700966Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-09-21T20:38:29.712909Z 0 [System] [MY-010931] [Server] /usr/local/mysql/bin/mysqld: ready for connections. Version: '8.4.2' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server - GPL.
2024-09-21T20:38:29.712908Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /tmp/mysqlx.sock
Pelo que posso perceber, não estou vendo nenhum erro sendo registrado. Mas, quando executo o seguinte script SQL, recebo um erro.
LOAD DATA INFILE '/private/var/lib/mysql-files/table.csv'
INTO TABLE Patients
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
IGNORE 1 ROWS;
ERRO:
The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
Tenho uma chave primária clusterizada descompactada. Ela consome 63,6 GB na parte principal do índice clusterizado com 17,9 GB LOB. O único índice não clusterizado da tabela é 57,3 GB também com 17,9 GB LOB. Desejo reconstruir o índice clusterizado offline sem que o banco de dados cresça. Executar sp_spaceusedsem argumentos relata 66 GB em sua coluna "espaço não alocado".
O que eu desejo fazer é possível? Ou reconstruir o índice compactado forçará uma reconstrução do índice não clusterizado, ocupando assim pelo menos 100 GB?
Apesar do meu melhor esforço, não encontrei uma resposta nem na documentação nem no Stack Overflow. Meus experimentos com um pequeno banco de dados que eu tinha à mão sugerem que reconstruir o índice clusterizado não força uma reconstrução dos índices não clusterizados.
Tenho o seguinte código em uma instância gerenciada do SQL Server Azure e o desempenho é bem ruim.
INSERT INTO #CU WITH (TABLOCKX) (LA_ID, CU_ID)
SELECT la.LA_ID,
c2.CU_ID
FROM #la la
INNER JOIN dbo.T1 c ON c.CU_ID = la.CU_ID
INNER JOIN dbo.T1 c2 ON c2.Parent_CU_ID = c.Parent_CU_ID
WHERE c.Parent_CU_ID > 0
AND c.CU_ID <> c2.CU_ID
AND la.Flag1 = 1
AND EXISTS (SELECT 1 FROM #cid WHERE c2.CU_ID = ID)
Tenho um índice filtrado em T1.Flag, e se eu remover a desigualdade o desempenho é mais do que aceitável (5 minutos para 10 segundos), então estou confiante de que meu problema é com a desigualdade, mas não consigo pensar em nenhum padrão que me dará os mesmos resultados, mas terá um desempenho melhor. Alguma sugestão? Plano
Tenho duas consultas diferentes, cada uma delas é executada muito rápido (em milissegundos).
Consulta 1:
select t1.id
from table1 t1
left join table2 t2 on t1.id = t2.t1_id
where (t1.update_date >= :timestamp1 AND t1.update_date < :timestamp2);
Consulta 2:
select t1.id
from table1 t1
left join table2 t2 on t1.id = t2.t1_id
where (t2.update_date >= :timestamp1 AND t2.update_date < :timestamp2);
Quando tento executar uma terceira consulta com uma condição que inclui as condições das duas primeiras consultas, a consulta fica muito lenta (segundos ou minutos, dependendo do tamanho da tabela):
Consulta 3.
select t1.id
from table1 t1
left join table2 t2 on t1.id = t2.t1_id
where (t1.update_date >= :timestamp1 AND t1.update_date < :timestamp2)
or (t2.update_date >= :timestamp1 AND t2.update_date < :timestamp2);
Parece que parte do problema é que o BD tem que escanear todas as linhas em t1. Sei que posso melhorar essa consulta e obter o resultado que quero usando UNIONing os resultados das duas primeiras consultas. Mas gostaria de saber qual é o motivo exato pelo qual o otimizador do MySQL (ou possivelmente de qualquer outro BD relacional) não consegue otimizar essa consulta sozinho?
Existe algum impedimento teórico para otimizadores que os impeça de fazer esse tipo de otimização?
Detalhes adicionais
Versão resumida das definições de tabela e declarações explicativas:
Tabela 1:
CREATE TABLE `table1` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
-- ... lots of other field definitions...
`update_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `update_date` (`update_date`),
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb3 ROW_FORMAT=COMPACT
Tabela 2:
CREATE TABLE `table2` (
`t1_id` int unsigned NOT NULL,
`update_date` timestamp NULL DEFAULT NULL,
PRIMARY KEY (`t1_id`),
KEY `update_date` (`update_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
A consulta 1 explica:
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+------+----------+--------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+------+----------+--------------------------+
| 1 | SIMPLE | t1 | NULL | range | update_date | update_date | 4 | NULL | 1 | 100.00 | Using where; Using index |
| 1 | SIMPLE | t2 | NULL | eq_ref | PRIMARY | PRIMARY | 4 | t1.id | 1 | 100.00 | Using index |
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+------+----------+--------------------------+
A consulta 2 explica:
+----+-------------+--------+------------+--------+-----------------------+---------------+---------+-----------------------+------+----------+--------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+--------+-----------------------+---------------+---------+-----------------------+------+----------+--------------------------+
| 1 | SIMPLE | t2 | NULL | range | PRIMARY,update_date | update_date | 5 | NULL | 1 | 100.00 | Using where; Using index |
| 1 | SIMPLE | t1 | NULL | eq_ref | PRIMARY | PRIMARY | 4 | t2.t1_id | 1 | 100.00 | Using index |
+----+-------------+--------+------------+--------+-----------------------+---------------+---------+-----------------------+------+----------+--------------------------+
A consulta 3 explica:
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+----------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+----------+----------+-------------+
| 1 | SIMPLE | t1 | NULL | index | update_date | update_date | 4 | NULL | 10271767 | 100.00 | Using index |
| 1 | SIMPLE | t2 | NULL | eq_ref | PRIMARY | PRIMARY | 4 | t1.id | 1 | 100.00 | Using where |
+----+-------------+--------+------------+--------+---------------+-------------+---------+---------------+----------+----------+-------------+
Estou trabalhando na migração do SQL Server do SQL 2016 para o SQL 2022.
Tenho um processo em que, após o banco de dados ser restaurado (para o estado "Standby / Somente leitura") da fita completa (de um terceiro fornecedor), devo adicionar cada arquivo de log por hora (bak) a esse banco de dados "Standby / Somente leitura".
Eu estava tentando executar o código T-SQL que estava funcionando no SQL 2016 (nos últimos 4 anos) neste novo ambiente (SQL 2022), e a primeira mensagem de erro que recebi foi nesta parte:
EXEC master.sys.xp_cmdshell @cmd
Então, pesquisei no Google e executei este código:
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
Quando executei o código, parece não haver nenhuma mensagem de erro, mas não vejo o arquivo de log do banco de dados aumentar de tamanho.
Estou colocando todo o meu código T-SQL aqui para referência:
USE Master;
GO
SET NOCOUNT ON
-- 1 - Variable declaration
DECLARE @dbName sysname
DECLARE @fileName sysname
DECLARE @standby sysname
DECLARE @backupPath NVARCHAR(500)
DECLARE @cmd NVARCHAR(500)
DECLARE @fileList TABLE (backupFile NVARCHAR(255))
DECLARE @lastFullBackup NVARCHAR(500)
DECLARE @lastDiffBackup NVARCHAR(500)
DECLARE @backupFile NVARCHAR(500)
-- 2 - Initialize variables
SET @dbName = 'us_xxxx_multi_replica1'
SET @fileName = 'LOG_us_xxxx_multi_replica'
SET @backupPath = 'F:\Yesterday\'
SET @standby = 'F:\us_xxxx_multi_replica_RollbackUndo_2024-09-17_19-33-23.bak'
-- 3 - get list of files
SET @cmd = 'DIR /b "' + @backupPath + '"'
INSERT INTO @fileList(backupFile)
EXEC master.sys.xp_cmdshell @cmd
-- 5 - check for log backups
DECLARE backupFiles CURSOR FOR
SELECT backupFile
FROM @fileList
WHERE backupFile LIKE '%.bak'
AND backupFile LIKE @fileName + '%'
OPEN backupFiles
-- Loop through all the files for the database
FETCH NEXT FROM backupFiles INTO @backupFile
WHILE @@FETCH_STATUS = 0
BEGIN
SET @cmd = 'RESTORE LOG [' + @dbName + '] FROM DISK = '''
+ @backupPath + @backupFile + ''' WITH STANDBY = ''' + @standby + ''''
FETCH NEXT FROM backupFiles INTO @backupFile
EXEC (@cmd)
END
CLOSE backupFiles
DEALLOCATE backupFiles
Abaixo está um exemplo de resultado após o processamento no SQL 2022 (com o qual estou tendo um problema):
Processed 0 pages for database 'us_xxxx_multi_replica', file 'us_template_pccmulti_rrdb_replica' on file 1.
Processed 952 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica_log' on file 1.
System objects could not be updated in database 'us_xxxx_multi_replica' because it is read-only.
System objects could not be updated in database 'us_xxxx_multi_replica' because it is read-only.
RESTORE LOG successfully processed 952 pages in 1.845 seconds (4.029 MB/sec).
Abaixo está um exemplo de resultado após execução no SQL 2016 (onde não há problema):
Processed 2336 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica_log' on file 1.
System objects could not be updated in database 'us_xxx_multi_replica' because it is read-only.
System objects could not be updated in database 'us_xxx_multi_replica' because it is read-only.
RESTORE LOG successfully processed 2336 pages in 0.531 seconds (34.361 MB/sec).
Processed 0 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica' on file 1.
Qual pode ser o problema?
BTW, quando o SQL 2022 foi instalado nesta VM, o SQL 2019 já estava instalado (veio com a VM). Nossa TI instalou o SQL 2022 manualmente, então estou me perguntando se há algum tipo de problema de permissão/configuração que não foi definido corretamente.
Porque quando executei este código T-SQL no SQL 2019, não encontrei o problema de
EXEC master.sys.xp_cmdshell @cmd
desde o começo.
Atualizar:
Não descobri o motivo pelo qual tive que resolver o problema com 'xp_cmdshell' no SQL 2022 (mas não no SQL 2019), mas está funcionando bem.
Percebi que o arquivo ldf no SQL 2016 não mostrou aumento de tamanho, mas apenas aumento no arquivo mdf. Então, acho que não preciso me preocupar com nenhuma alteração no tamanho do arquivo ldf.
Consegui ver as diferenças verificando os dados em si.
Eu tenho 2 mesas
table1
emp type
tom 1
tom 2
table2
emp grade
tom a
tom b
tom c
Esperar retorno
emp type grade
tom 1 a
tom 2 b
tom c
a consulta parece correta, mas não totalmente correta
select table1.emp , table1.type, table2.emp, table2.grade
from table1
left join table2 on table1.emp = table2.emp
return
emp type grade
tom 1 a
tom 1 b
tom 1 c
tom 2 a
tom 2 b
tom 2 c
Temos um banco de dados de grupo de disponibilidade com 4 servidores que inclui uma réplica assíncrona que é usada para relatórios. Às vezes, devido a grandes conjuntos de consultas, a réplica secundária interrompe a sincronização e temos que retomar a sincronização manualmente.
Também queremos instalar o SSRS na réplica secundária que usamos para relatórios.
Aqui estão minhas perguntas abaixo
Vale a pena o impacto no desempenho ao instalar o SSRS na réplica secundária, já que não temos licença Enterprise para instalar o SSRS em um host separado?
Podemos separar o servidor de relatório secundário e sincronizar os dados por meio do SSIS? Assim, haverá 3 servidores de banco de dados de grupo de disponibilidade de nós e um servidor de relatório separado que sincroniza por meio do SSIS ou algum outro formato.
No geral, é aconselhável EXECUTAR o SSRS na réplica secundária. Obrigado pela contribuição
Sempre que executo esta consulta:
SELECT trade_detail_id,trade_side_id,id,is_last,is_xml_detail_filled,save_date_time,trade_id,trade_ligne_id,type,xml_detailled_info,xml_state
FROM some_table
WHERE (NOT (is_xml_detail_filled =1))
O SQL Server envia de volta este erro:
Msg 8649, Nível 17, Estado 1, Linha 12
A consulta foi cancelada porque o custo estimado desta consulta (1191) excede o limite configurado de 12. Entre em contato com o administrador do sistema.
Em sp_configure, o limite de custo do governador de consulta é definido como 0.
Em Propriedades do servidor -> conexões , "Usar o controlador de consulta para evitar consultas de longa execução" está desabilitado.
DBCC USEROPTIONSnão menciona nada
Então por que o erro?
Se eu usar SET QUERY_GOVERNOR_COST_LIMIT, o erro desaparece, mas eu não deveria precisar usar esse comando aqui se não houver limites em todo o servidor.
Instância do SQL Server 2019 CU28 no Windows 2019.