ABS's questions

Estou tentando implementar a replicação de mesclagem entre apenas dois servidores, um editor e um assinante.

Suponha estas tabelas:

--Main table in Publisher
Ticket (id, userId, reqId, blockedDate, usedDate, returnDate, transferDate, ...)

--On Subscriber (The fields are in Publication)
Ticket (id, userId, blockedDate, usedDate)

Devemos atribuir a data atual transferDatesempre que uma linha for para o Assinante e atribuir returnDatesempre que ela voltar do Assinante. Como temos que considerar uma sincronização de arquivo (transferência/retorno de dados de/para o assinante com um pendrive!), esses campos devem ser atribuídos na sincronização na sincronização de arquivo ou na replicação.

Eu sei que você pode adicionar sua lógica de negócios personalizada para resolução de conflitos (quando ocorre um conflito). Estou procurando algo como gatilhos para eventos de replicação, que me dão a capacidade de manipular alguns campos fora da Publicação (ou até mesmo outra tabela sempre que necessário).

Perguntas

• É possível lidar com eventos de replicação (push e pull) manualmente?** (personalize ou substitua PULL/PUSH's. Não resolvedor de conflitos)**

• Você pode me dar uma comparação entre implementar uma replicação de mesclagem personalizada e sincronizar com a ajuda de um distributed transactionSP?

Eu preciso que a sincronização seja agendada (à meia-noite quando não há carga no servidor de banco de dados), MAS é altamente necessário que possamos sincronizar manualmente (de dentro de nosso aplicativo da web).

Na segunda pergunta, preciso de seu desempenho, confiabilidade e, claro, sua capacidade de manutenção. Esses fatores, especialmente os dois primeiros, são uma grande preocupação. Suponha que o Publicador possa ter cerca de milhões de registros e o Assinante possa ter cerca de dez mil. Assim, a cada sincronização, cerca de dez mil registros serão transferidos.

A replicação de mesclagem verifica as linhas; se houver uma alteração e não houver um conflito, a linha será mesclada. se houver um conflito, um resolvedor de conflitos (pode ser seu resolvedor de procedimento armazenado personalizado) lidará com o conflito. Eu quero escrever minha própria lógica no primeiro caso (dados alterados sem conflito) em vez do mecanismo de mesclagem interno do SQL. Claramente eu quero personalizá-lo.

Há apenas id, userId, blockedDate, usedDatecolunas no artigo. Eu quero preencher returnDatesempre que a Ticketvoltar para o Publisher (em um pull ) e preencher transferDatesempre que Ticketfor para o Subscriber (em um push ).

Como descobri, você pode definir um bloqueio na tabela desejada em uma transação com:

begin tran
    select 1 from myTable
        with (tablock /*or tablockx to block even reads from table*/, holdlock) 
    -- do your work
commit tran

Mas quando executo este código em uma tabela de servidor vinculado, a tabela ainda pode ser acessada de dentro do servidor vinculado! Por quê? Como posso definir um bloqueio nesta tabela remota como meu exemplo?

Suponha esta estrutura de banco de dados:

--On main server(server)
TicketRequest (id, date, count, start, end/*,and some other columns*/)
Ticket (id, reqId, blockedDate, usedDate, userId/*,and some other columns*/)
--and some other tables

--On linked server(gate)
--Just this table
Ticket (id, userId, blockedDate, usedDate)

A Ticketpode usar no portão, então no portão só usedDatepode mudar.

No servidor, um Ticketpode ser bloqueado, excluído; ou após importar os dados do gate, defina seu arquivo usedDate.

Quero sincronizá-los online.

Eu escrevi sp_server_export , sp_gate_import para transportar dados do servidor e sp_gate_export , sp_server_import para transportar dados do portão, para sincronizá-los por meio de um arquivo (um arquivo server_export vai para o portão e o arquivo server_import volta para o servidor).

Eu usei MERGEe seu desempenho é muito bom! Agora, quando estou tentando encontrar uma solução para sincronizar o servidor com o portão, depois de algumas pesquisas, infelizmente, a Microsoft diz: MERGEnão está funcionando na tabela remota como destino!

Então, como posso sincronizar com uma transação do servidor?!

NOTA: Como nosso plano, a sincronização deve ser executada apenas a partir do servidor! O operador do portão não pode alterar o DB!

NOTA IMPORTANTE: Considere que a simultaneidade é minha primeira preocupação! Eu quero sincronizar enquanto um usuário pode excluir um Ticket! Ou Ticketpode bloquear ao mesmo tempo! Ou no portão um Ticketpode usar!

ATUALIZAR :

Nossa lógica de sincronização é:

1 - excluir ingressos antigos (que retornaram com uma sincronização de arquivos e têm returnDatee têm modificationDate >um carimbo de data/hora de um mês depois para garantir a exclusão de ingressos usados ​​do portão)

2 - atualização gate.ticket onde usedDate é null set blockDate = server.blockDate;

3 - insira novas linhas do servidor

4 - defina transferDate para ingressos transferidos para o portão (quero dizer ingressos novos/atualizados nas etapas 2 e 3)

5 - atualize server.Ticket.usedDate de gate.Ticket onde gate.Ticket.usedDate não é nulo. (isso enviará tickets usados ​​do portão de volta ao servidor)

6 - insira um transferLog ( na tabela transferLog no servidor )

Eu preciso de um SP (ou algo assim) que deve ser capaz de fazer algumas alterações em tabelas específicas e retornar o conteúdo de uma delas.

Algo como este pseudo-código:

create procedure
    begin
        begin transaction
            update myTable set transferDate = GETDATE() where condition;
            insert into transferLog values(@userId, GETDATE());
        commit transaction

        return myTable data
    end

NOTA: Se houver uma pergunta semelhante, por favor , encaminhe-me para ela.

Eu tenho duas tabelas Request& Receipt.

Eu quero que a tabela Receiptpermaneça bloqueada para operações CRUD de qualquer lugar até que a transação seja concluída. Eu preciso que a transação esteja em um procedimento armazenado.

É impossível? Como?

Por que deve Receiptpermanecer bloqueado? Porque uma solicitação interna de inserção ou exclusão Receiptnão poderá manipulá-la! Observe que eu preciso ReceiptIdser consecutivo por cada um Requestde seu startpara seu finish!