cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction log becomes full on primary

Former Member
0 Kudos

Hello,

being forced to learn Replication Server by myself and alone, I have tons of "simple" questions.

Replication is set in a way that there is one primary database, one RS, two replica databases, which are set in a MSA way, not Warm/Standby.

On primary database transaction log is full, and I see that message in a trace of RS as well.

So, here are my questions:

1. primary database has an option trunc log on checkpoint, abort tran on log full. If we have primary database 50 GB of data, and 5 GB of tran log, and if tran log is almost full - can it become full by the fact that for example, replication agent is not transferring that transaction to the RS(if replication agent is down), although that transaction is committed? I have checked syslogs table for that huge transaction and saw by examining op column for the same xactid, that it contains only one begin tran and only one commit tran (and lots of inserts, updates and rollbacks - I have been using some questionable query to distinguish what op column in syslogs table means) . So, it looks like that it is committed(if it is correct way to make that conclusion).

2. if inbound queue on RS for that database is almost full(29 of 30GB) because of some reason(what could be the reason?) will some process(which one?) start transferring committed transaction from primary to the inbound queue? Does only committed transactions are moved from primary to the RS? Can full inbound queue also causing that transaction log on primary becomes full?

3. Is there any picture in Sybase RS documentation which describes the processes and structures which are included in replication process, and explain the flow of the data between them?

4. how can I conclude if transaction log on primary is full because of problem with replication, or is it full regardless of replication?

5. Can I run dump transaction with truncate_only on primary database, without fear that it will somehow delete data which are not replicated? And is it necessary to be done, because the primary database is already set with "trunc log on checkpoint" option? Is it ok to have that option for databases which are included into replication?

6. Since maybe I am going in totally wrong direction(my questions maybe reveal that), what is a usual way of solving this problem - primary database log full and inbound queue on RS full?

6. any other pointing to some useful documentation addressing architecture of RS and RS processes, structures and other information are welcomed.

Thank You.

Best regards,

Vojislav Depaliv

Accepted Solutions (0)

Answers (0)