[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dec_data_distributor

Title:	The Replication Option for Rdb
Notice:	Product renamed to Replication Option for Rdb
Moderator:	BROKE::PROTEAU

Created:	Wed Mar 02 1994
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	287
Total number of notes:	1231

200.0. "Help !" by RUBY::MOSS () Tue Apr 02 1996 13:13

	I have a DDD copy running, that isn't doing anything except eating CPU. 
It has the database open, and even if I issue a STOP TRANSFER command, it
doesn't release it, it keeps it open.  So far as I can determine, this was
caused by the target node dropping off the network, and for whatever reason, DDD
didn't shut the copy down.  I restarted the copy (Stop, Reinit, Start) but it
just went into what appears to be a loop.

	Can I kill the DDD copy process without corrupting the source database -
I don't care about the target one, what matters is getting users back into the
source database.   Can anyone help ???????


Thanks 

Charles Moss

T.R	Title	User	Personal Name	Date	Lines
200.1	Go ahead and kill the copy process	BROKE::PROTEAU	Jean-Claude Proteau	`Tue Apr 02 1996 13:38`	3
	Yes, go ahead and kill the copy process. Any transaction it had open onthe source database will be automatically rolled back by the database system.
200.2	Configuration?	BROKE::PROTEAU	Jean-Claude Proteau	`Tue Apr 02 1996 13:47`	13
	I've only heard of a similar situation from one other customer. I've no idea whether the problem is with Data Distributor, the software it talks to, or hardware. That is, the amount of information avilable on the problem is slim, so I couldn't even hazard a guess as to what was going on. I'd like to compare your hardware and software configuration with that of the other customer just to see if they are nearly the same. What cpu's do you have at the source and target sites? What type of hardare connection do you use for the network link? What version of Data Distributor do you have? What versions of the source and target database systems do you use? What type of transfer was being executed?
200.3	Thank you !!	RUBY::MOSS		`Wed Apr 03 1996 09:54`	12
	It worked, and it didn't injure the database, thankfully ! I will post the requested info as soon as I get chance - the one thing I was told was that the target node "fell off the FDDI ring" - I don't know that that is different from the node crashing, or the network crashing, but... By doing a Stop/id=, I don't suppose anything of any use will be left out there ? Thanks again, Charles
200.4	Usefulness of the log	BROKE::PROTEAU	Jean-Claude Proteau	`Wed Apr 03 1996 10:11`	22
	Well, you can always look at the transfer's log file. We call this the coy process log file to distinguish it from the transfer monitor's log file. That log file is named in the transfer definition, which you can see using SHOW TRANSFER (DEFINITION) xxx; using SQL. Whether or not there's anything helpful there I can't say. As I said, the information at hand on this type of problem is slim. My thought for a future diagnostic feature would be to add an option for Data Distributor to keep track of how many calls it makes to the database system. Then, after every N calls (perhaps specifiable by the customer), Data Distributor would log some informational message. How might this help? Well, if you know it is trying to transfer 1000 rows of data from one database to another but it says it had to perform 1,000,000 database calls, there's something wrong and Data Distributor might be a part of what's wrong. If it says it's making only 1000 database calls but the I/O activity on the database system is exhorbitantly high, that would indicate a probable internal database system error (or perhaps a hardware error). It's not much of a diagnostic aid, I agree. Any ideas?