Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
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.