Ambiente: Microsoft SQL Server 2014 - 12.0.4100.1 (X64) 20 de abril de 2015 17:29:27 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) no Windows NT 6.3 (Build 9600: ) (Hypervisor)
Quando altero a taxa de crescimento do arquivo de log na réplica primária, o banco de dados da réplica secundária obtém essa alteração e posso verificar na GUI e na sys.database_files
exibição. Mas a mesma mudança não reflete em sys.master_files
vista.
Código de configuração
:Connect PrimaryNode
IF EXISTS(SELECT name FROM sys.databases
WHERE name = 'FileGrowthTest]')
DROP DATABASE FileGrowthTest
GO
CREATE DATABASE [FileGrowthTest]
ON PRIMARY
( NAME = N'FileGrowthTest', FILENAME = N'L:\FileGrowthTest.mdf' , SIZE = 4096KB , FILEGROWTH = 10%)
LOG ON
( NAME = N'FileGrowthTest_log', FILENAME = N'F:\FileGrowthTest_log.ldf' , SIZE = 4096KB , FILEGROWTH = 10%)
GO
BACKUP DATABASE [FileGrowthTest] TO
DISK = N'E:\Backup\FileGrowthTest.bak'
WITH NOFORMAT, NOINIT, NAME = N'FileGrowthTest-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.
:Connect PrimaryNode
USE [master]
GO
ALTER AVAILABILITY GROUP [TestAG]
ADD DATABASE [FileGrowthTest];
GO
:Connect PrimaryNode
BACKUP DATABASE [FileGrowthTest] TO DISK = N'\\backupshare\FileGrowthTest.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO
:Connect SecondaryNode
RESTORE DATABASE [FileGrowthTest] FROM DISK = N'\\backupshare\FileGrowthTest.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO
:Connect PrimaryNode
BACKUP LOG [FileGrowthTest] TO DISK = N'\\backupshare\FileGrowthTest.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO
:Connect SecondaryNode
RESTORE LOG [FileGrowthTest] FROM DISK = N'\\backupshare\FileGrowthTest.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO
:Connect SecondaryNode
-- Wait for the replica to start communicating
begin try
declare @conn bit
declare @count int
declare @replica_id uniqueidentifier
declare @group_id uniqueidentifier
set @conn = 0
set @count = 30 -- wait for 5 minutes
if (serverproperty('IsHadrEnabled') = 1)
and (isnull((select member_state from master.sys.dm_hadr_cluster_members where upper(member_name COLLATE Latin1_General_CI_AS) = upper(cast(serverproperty('ComputerNamePhysicalNetBIOS') as nvarchar(256)) COLLATE Latin1_General_CI_AS)), 0) <> 0)
and (isnull((select state from master.sys.database_mirroring_endpoints), 1) = 0)
begin
select @group_id = ags.group_id from master.sys.availability_groups as ags where name = N'TestAG'
select @replica_id = replicas.replica_id from master.sys.availability_replicas as replicas where upper(replicas.replica_server_name COLLATE Latin1_General_CI_AS) = upper(@@SERVERNAME COLLATE Latin1_General_CI_AS) and group_id = @group_id
while @conn <> 1 and @count > 0
begin
set @conn = isnull((select connected_state from master.sys.dm_hadr_availability_replica_states as states where states.replica_id = @replica_id), 1)
if @conn = 1
begin
-- exit loop when the replica is connected, or if the query cannot find the replica status
break
end
waitfor delay '00:00:10'
set @count = @count - 1
end
end
end try
begin catch
-- If the wait loop fails, do not stop execution of the alter database statement
end catch
ALTER DATABASE [FileGrowthTest] SET HADR AVAILABILITY GROUP = [TestAG];
GO
GO
Ambos os arquivos têm uma taxa de crescimento de 10% agora. Mudando para valor fixo.
USE [master];
GO
ALTER DATABASE FileGrowthTest MODIFY FILE (NAME='FileGrowthTest', FILEGROWTH = 256MB);
ALTER DATABASE FileGrowthTest MODIFY FILE (NAME='FileGrowthTest_log', FILEGROWTH = 128MB);
GO
A alteração é visível no nó de réplica secundário ao usar sys.database_files
a exibição para dados e arquivos de log.
USE [FileGrowthTest];
GO
SELECT name AS file_name,
type_desc AS file_type,
growth AS current_percent_growth
FROM sys.database_files
WHERE is_percent_growth=1
Mas usando sys.master_files
apenas a visualização, a alteração do arquivo de dados é visível. O crescimento do arquivo de log ainda mostra 10%.
SELECT d.name as database_name,
mf.name as file_name,
mf.type_desc as file_type,
mf.growth as current_percent_growth
FROM sys.master_files mf (NOLOCK)
JOIN sys.databases d (NOLOCK) on mf.database_id=d.database_id
WHERE is_percent_growth=1
AND d.name='FileGrowthTest'
GO
Por sys.master_files
que não reflete a alteração da taxa de crescimento automático do arquivo de log, enquanto a alteração do crescimento automático do arquivo de dados é refletida corretamente?
Este é um problema conhecido, suspeito que
master
no secundário não será gravado imediatamente, e talvez não até que essa instância se torne a primária. O problema ainda está "em análise" de acordo com este bug apresentado por Nic Cain em 2015:Até que isso seja resolvido, recomendo usar
sys.database_files
em vez desys.master_files
, embora saiba que isso nem sempre é conveniente.Veja também este tópico do fórum , este tópico do fórum e a postagem do blog de Nic sobre esse problema .
Eu tento pensar
database_files
no escopo do banco de dados emaster_files
no escopo do instância . Eu já pensei sobre isso como significando que umdf
valor de atributo afetado será transportado na conclusão do comando, enquanto ummf
valor pode exigir uma reinicialização mais perturbadora fisicamente antes de " colar " em ambos os lados 1 .Talvez seja pró-forma apontar, mas ... a linha um de cada documentação oficial mostra a diferença (ênfase minha):
Não considero isso um bug. A leitura da réplica secundária desses dados não é "incorreta". Pode ser mais correto dizer que é "latente". Você já dirigiu semear um AG apenas para perceber que o banco de dados da réplica secundária tem um proprietário diferente da réplica primária? Talvez alguma configuração vinculada à instância como
trustworthy
não " pegou " na réplica secundária e você não possa " consertá -la" até o failover? É até possível fazer failover e depois failback sem corrigir esses atributos em alguns casos!?Perguntar a uma determinada fonte retornará os dados " corretos " para o escopo dessa fonte . Dando uma olhada no interior do
object_definition()
para cada exibição de catálogo, vemos quedatabase_files
é apontado primeirosys.sysprufiles
enquantomaster_files
está em primeiro lugarsys.sysbrickfiles
.Uma diferença levemente massageada dessas definições revela algo como o seguinte:
Brevemente...
database_id
ecredential_id
size
ephysical_name
type_desc
estate_desc
, o conjunto de linhas base difere conforme observado acima (mf =sysbrickfiles
| df =sysprufiles
)1. Certamente, o teste de casos extremos para diferentes atributos pode ser uma maneira divertida de perder alguns dias ... O OP menciona especificamente a taxa de crescimento do arquivo de log como o atributo que não está carregando. Se você pudesse criar um cenário em que o secundário visse a necessidade de aumentar automaticamente o tronco, mas não o primário... bem... quebrar as coisas pode ser divertido!