Temos um Banco de Dados SQL secundário que está constantemente sincronizando com o banco de dados primário. No passado, executei um procedimento armazenado no banco de dados secundário (mesmo enquanto ele estava sincronizando) com sucesso.
Por algum motivo, agora estou recebendo a seguinte mensagem de erro quando tento executar o mesmo procedimento armazenado
Failed to update database xxxxxx because the database is read-only.
O procedimento armazenado é o seguinte:
CREATE PROCEDURE dbo.GenerateDeltaTable
@Domain VARCHAR(100),
@TableName VARCHAR(100),
@DeltaTable VARCHAR(100)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @sql NVARCHAR(MAX);
-- Construct dynamic SQL for dropping and creating the target table
SET @sql = '
IF OBJECT_ID(''' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + ''', ''U'') IS NOT NULL
DROP TABLE ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + ';
SELECT T.*,
LOWER(CONVERT(VARCHAR(64), HASHBYTES(''SHA2_256'',
(SELECT T.* FOR JSON PATH, WITHOUT_ARRAY_WRAPPER, INCLUDE_NULL_VALUES)), 2)) AS signature
INTO ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + '
FROM ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@TableName) + ' AS T;';
-- Execute the constructed SQL
EXEC sp_executesql @sql;
END;
Alguém pode me dizer por que estou recebendo o erro de repente?
Ou existe alguma maneira de fazer com que o banco de dados SQL primário force a execução de um procedimento armazenado no banco de dados secundário?
Basicamente, existe uma maneira de superar a situação de somente leitura no banco de dados secundário?
Como Sean mencionou anteriormente nos comentários, seu procedimento armazenado está tentando gravar em um banco de dados somente leitura. Especificamente esta linha de código da
SELECT ... INTO
cláusula:Você está tentando executar isso em um banco de dados somente leitura, o que parece ser a réplica secundária em um AlwaysOn Availability Group. Isso não é permitido pelo design porque a réplica é somente leitura. Não há como consertar isso, porque as réplicas secundárias são sempre somente leitura, o que também é por design, para evitar que alterações sejam feitas em um banco de dados que deve ser completamente espelhado com uma réplica primária. Não importa se seu Availability Group está sincronizando ativamente ou não.
Uma solução alternativa seria modificar o procedimento para
SELECT ... INTO
uma tabela em um banco de dados diferente (que não seja somente leitura/não faça parte de um AlwaysOn Availability Group) que esteja no mesmo servidor. Por exemplo:De acordo com Erik,
tempdb
é um alvo popular para esse tipo de coisa. Faz sentido, já que cada instância tem umtempdb
, desde que você não esteja tentando persistir os resultados de forma mais permanente.