Habilitar a durabilidade atrasada

Alguns processos, como o planejamento de requisitos de material (MRP) do EnterpriseOne, podem enfrentar um gargalo causado pela latência do disco ao confirmar transações no log de transações. Mover o registro de transações (LDF) para o armazenamento do io2 ou io2 Block Express geralmente melhora a performance o suficiente para atender às necessidades de negócios. Se isso for insuficiente, você poderá configurar a durabilidade atrasada no banco de dados.

Importante

Habilite a durabilidade retardada somente se a performance não for aceitável e se você entender completamente como suas transações se comportarão nos bancos de dados durante cenários de falha do sistema.

Quando você ativa a durabilidade retardada, as confirmações de transações são armazenadas em cache usando uma operação de write-back (em vez de write-through). Em caso de falha no sistema, a consistência do banco de dados ainda é garantida. No entanto, todas as transações que não foram confirmadas em disco são perdidas. Além disso, as funcionalidades adicionais relacionadas à replicação, incluindo a funcionalidade usada pelo AWS Database Migration Service (AWS DMS), permanecerão indisponíveis quando a durabilidade atrasada estiver em vigor.

Durante o teste de MRP em uma configuração específica, observamos o seguinte:

• Mover o arquivo LDF para o io2 Block Express reduziu o tempo de execução em 52% em comparação com uma linha de base com o arquivo LDF no gp3.

• A habilitação da durabilidade atrasada reduziu o tempo de execução em 79% em comparação com uma linha de base com o arquivo LDF no gp3.

Para ativar a durabilidade atrasada, execute o comando a seguir no banco de dados.

USE master
ALTER DATABASE JDE_Prist920 SET DELAYED_DURABILITY = FORCE

A durabilidade atrasada normalmente descarrega o registro várias vezes por segundo, mas o atraso poderá ser maior se houver um gargalo de E/S do disco. Para garantir um objetivo de ponto de recuperação (RPO) baixo, é possível colocar o comando sys.sp_flush_log em um programador para execução em uma frequência elevada. Esse procedimento força a descarga do log para o disco.

O script a seguir cria um trabalho no programador de trabalhos do SQL para ser executado a cada minuto. Ajuste o nome do trabalho e o nome do banco de dados no script para refletir seus requisitos.

USE msdb;  
GO  

DECLARE  @myjob nvarchar(128);
DECLARE @mydb nvarchar(128);
DECLARE @mycommand nvarchar(max);
DECLARE @myschedule nvarchar(128);
DECLARE @jobId binary(16);
DECLARE @scheduleId binary(16);

SET @myjob = 'JDE_Prist920 Flush Log Cache';
SET @mydb = 'JDE_Prist920';
SET @mycommand  = 'sys.sp_flush_log';
SET @myschedule = 'EveryMinute';


SELECT @scheduleId = schedule_id FROM msdb.dbo.sysschedules WHERE (name = @myschedule)
IF (@scheduleId IS NULL)
BEGIN
	EXEC sp_add_schedule  
	    @schedule_name = @myschedule,  
	    @freq_type = 4,  
	    @freq_interval = 1,  
	    @freq_subday_type = 0x2,
	    @freq_subday_interval= 60
END

SELECT @jobId = job_id FROM msdb.dbo.sysjobs WHERE (name = @myjob)
IF (@jobId IS NULL)
BEGIN
    EXEC sp_add_job @job_name = @myjob

	EXEC sp_add_jobstep
	    @job_name = @myjob,
	    @step_name = N'process step',
	    @subsystem = N'TSQL',
		@command = @mycommand,
		@database_name = @mydb   

	EXEC sp_attach_schedule  
		@job_name = @myjob,   
		@schedule_name = @myschedule;  

	EXEC dbo.sp_add_jobserver  
		@job_name = @myjob

END