Eu tenho um banco de dados muito grande em nosso data warehouse, onde implementamos o particionamento para gerenciar a manutenção e os backups. Os registros de uma certa idade são eventualmente migrados para um grupo de arquivos somente leitura uma vez por mês.
Ocasionalmente, nosso processo ETL tenta atualizar registros mais antigos que já foram migrados para o archive e esperamos que eles falhem. No entanto, tenho pelo menos dois exemplos recentes em que o registro em teste é atualizado, mesmo quando parece estar em uma partição no grupo de arquivos somente leitura em nosso ambiente de teste (consulta sys.partition_functionse sys.partition_range_values).
Um registro idêntico na produção causa a falha esperada ao tentar atualizar o registro. Nas duas vezes que capturamos isso até agora, a atualização falha na produção, mas é bem-sucedida no teste (nunca o contrário).
Fatos relevantes do ambiente:
- SQL Server 2012 SP3 CU3 (compilação 11.0.6537.0)
- Teste é edição do desenvolvedor, produção é empresa
- Pode fornecer outras pessoas conforme solicitado: seriamente perplexo agora ...
ATUALIZAÇÃO 19/08/2016
Novos registros foram atualizados de alguma forma da noite para o dia. Confirmado que estava no grupo de arquivos somente leitura. Constatou que eu posso atualizar registros que foram inseridos ao mesmo tempo (ou seja, também estão na mesma partição no grupo de arquivos somente leitura). Identifiquei um único registro na mesma partição e consegui atualizá-lo várias vezes. Tentativas de atualização do registro atualizado durante a noite resultam na falha esperada.
ATUALIZAÇÃO 11-08-2016
As atualizações continuam a ocorrer durante o processamento noturno em teste na partição somente leitura. A tentativa de atualizar os mesmos registros do processo falha. Tentativa de atualizar os mesmos registros durante o logon do usuário que o atualizou anteriormente falhou. Também não consigo duplicar o problema atualizando um registro semelhante que ainda não foi tocado pelo processo noturno.
ATUALIZAÇÃO 04-08-2016
Descobri hoje que não está limitado a essa tabela única, pois descobri outra ocorrência do mesmo comportamento em uma tabela diferente usando o mesmo esquema de partição.
ATUALIZAÇÃO 03/08/2016
Executar o script a partir Este script MSDN confirma o que eu recebo quando utilizar vistas de Kendra Pequenas partição auxiliares ph.FilegroupDetaile ph.ObjectDetailde esta demonstração . O registro em questão está na partição 2 (o valor da coluna da partição para o registro em questão é 18/03/2015)
Filegroup Low Boundary UpperBoundary
Archive (RO) NULL 1900-01-01
Archive (RO) 1900-01-01 2015-04-01
ActiveFG (RW) 2015-04-01 2015-07-01
ActiveFG (RW) 2015-07-01 2015-10-01
ActiveFG (RW) 2015-10-01 2015-01-01
ActiveFG (RW) 2016-01-01 2016-04-01
ActiveFG (RW) 2016-04-01 2016-07-01
ActiveFG (RW) 2016-07-01 2016-10-01
ActiveFG (RW) 2016-10-01 2017-01-01
ActiveFG (RW) 2017-01-01 2115-01-01
ActiveFG (RW) 2115-01-01 NULL
Código para colocar a tabela na partição (não há outros índices)
ALTER TABLE [dbo].[TABLE_NAME] ADD CONSTRAINT [pk_TABLE_NAME] PRIMARY KEY CLUSTERED
(
[ETL_VERS_START_DTM] ASC,
[ACCT_NO] ASC,
[ACCT_TYPE] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ps_SmallTablesDate(ETL_VERS_START_DTM)
A declaração de atualização que deve falhar (via Informatica):
UPDATE TABLE_NAME SET ETL_JOB_SEQ_NUM = ?, ETL_IUD_CD = ?, ETL_UPD_DTM = ?, ETL_DEL_DTM = ? WHERE ETL_VERS_START_DTM = ? AND ACCT_NO = ? AND ACCT_TYPE = ?
ETL_VERS_START_DTM (ETL_VERS_START_DTM:Date:): "03/17/2015 23:30:02.140000000"
ETL_JOB_SEQ_NUM (ETL_JOB_SEQ_NUM:Int:): "1173651"
ETL_IUD_CD (ETL_IUD_CD:Char.1:): "D"
ETL_UPD_DTM (ETL_UPD_DTM:Date:): "08/02/2016 02:32:45.000000000"
ETL_DEL_DTM (ETL_DEL_DTM:Date:): "08/02/2016 00:10:03.567000000"
ACCT_NO (ACCT_NO:Char.12:): "1234567890"
ACCT_TYPE (ACCT_TYPE:Char.3:): "OLN"
UPDATE 2017-02-21
Portanto, depois de todo esse tempo, descobrimos que, de alguma forma, quando a partição ativa mais antiga estava sendo mesclada no archive, uma seção de registros não foi movida no disco do grupo de arquivos ativo para o grupo de arquivos archive. A consulta a seguir mostra que os registros da partição 2 foram mapeados para o ActiveFG enquanto a inspeção do esquema de particionamento real mostra que esses mesmos registros devem ser classificados no grupo Arquivar arquivos pela função de partição.
SELECT OBJECT_NAME(P.[object_id]) ,
P.index_id ,
P.partition_number ,
F.name ,
F.filegroup_guid
FROM sys.allocation_units AU
JOIN sys.partitions P ON P.partition_id = AU.container_id
JOIN sys.filegroups F ON F.data_space_id = AU.data_space_id
WHERE P.partition_number IN ( 1, 2, 3 )
AND P.[object_id] = OBJECT_ID('TABLE_NAME')
ORDER BY P.partition_number;
Eu fiz backup de todo o particionamento nos bancos de dados em uso reais e mantive uma versão da que estava quebrada para trabalhar com o ticket da Microsoft. Preciso revisar o plano de particionamento com nossa equipe de DW, mas admito que sou um pouco tímido ao tentar novamente.
A Microsoft não conseguiu duplicar esse comportamento e, portanto, é feito com o ticket no momento. Eles parecem prontos para simplesmente dar de ombros e assumir que não está presente em 2014/2016? Eles não conseguem replicá-lo em seus laboratórios, apesar da minha capacidade de continuar existindo no banco de dados, mesmo depois que eu o restauro no sistema.