Been having some horrible problems with Replication at a client site. The biggest one is that when trying to disable replication in order to resynch it later the dsrutil command hangs itself up waiting for the repl server to finish. As it's Windows there's nothing I can do to prevent this crashing the database. See attached screenshot.
I can disconnect the process from the DB and whilst it visually goes away in the user list, it's still in _connect so killing the window stops the DB.
What causes this to happen? 10.2B07. Is it something that's fixed, or something I can fix by changing configurations or some such thing? I'm a little wary of re-enabling replication on this database in case it happens again and we can't afford to have to plan more downtime.
I've never encountered this issue before but it's proving to be an embarrassment with our client.
1. what is the current status of your ai files, are they perhaps all LOCKED?
2. is the database perhaps in a stalled state bistall or ai stall for example?
> As it's Windows there's nothing I can do to prevent this crashing the database
What options would you have had it not been Windows?
Hi Ruanne, no the ai's weren't all locked, and the database wasn't stalled. People were using it just fine. Neither of the stall options are active.
kirchner No idea in detail but I gather you can at least try different levels of kill that are less likely to crash the DB.
I also don't know. But AFAIK unless you can get the process to willingly and gracefully terminate you risk crashing the database.
> But AFAIK unless you can get the process to willingly and gracefully terminate you risk crashing the database.
Often a process is not terminated willingly only because it's rolling back its transaction. In this case the risk to crash db by using kill -9 is rather close to 100% (roughly 80-90%).
Db will be crached if a process is holding a latch or if it's holding or just waiting for a buffer lock. But if the process is waiting for something else it can be killed toughly.