September 27, 2007 at 3:29 pm
Hey Group:
I'm a newbie learning on my own because our organization had a need and I was there. I've been working (and learning) with MSSQLServer 2000 for about a year and a half - other duties as assigned - so I'm not a fulltime DBA but would like to be. I need some help with an issue betweene two machines with the following:
MS Windows 2000 Server v.5.0.2195 SP4 Build 2195
SQL Server 2000 v. 8.00.818 SP3.
Here's my scarey scenario:
Our IT Sys Tech Specialist recently virtualized our PRD Server to create a new DEV server - needed new hardware. Now there's a reciprocal relationship between the two machines such that when a record is updated or a new record is added to the database on either machine, the other machine is updated with the same data.
The procedure was done because we were experiencing problems with our previous development box. The procedure involved imaging to a new machine & then applying sysprep. I've already made sure on both machines that MSSQL Server Remote Server Connections settings "Allow other SQL Servers to connect remotely to this SQL Server using RPC"
are unchecked.
Are there any other known issues that might need to be addressed? Where should I start? Need all the help I can get!
Thanks,
Trez
Theresa "Trez" Moreland
Maryland Dept of Budget & Mgt
OIT/EIS/Service Desk
Annapolis, MD
September 28, 2007 at 9:13 am
I have a small issue digesting the post
Situation before:
1 Production server A (reel or virtual)
Situation in between
Cloned A to create developserver B (vm)
Current situation
Prod A reel
Dev B virtual
Do A & B have the same server names?
Both are "default" instances or are they named?
issue:The mirroring between A & B shouldn't happen.
*Check both server names
*Start a sql profile to identify the creator of duplicate items.
*Is there one application involved or are there multiple?
September 28, 2007 at 11:09 am
Hi Jo - thanks for the quick reply - sorry about issues digesting ... I'm still learning.
You are correct in your overview of the situation:
Situation before:
1 Production server A (reel) CORRECT
Situation in between
Cloned A to create developserver B (vm) CORRECT
Current situation
Prod A real CORRECT
Dev B virtual CORRECT
Do A & B have the same server names? YES
Both are "default" instances or are they named? DEFAULT
issue:The mirroring between A & B shouldn't happen CORRECT
*Check both server names -
Prod A Name= AR-AN01P
Dev B Name = AR-AN01D
*Is there one application involved or are there multiple? ONLY ONE APPLICATION - BMC'S REMEDY ARS
* Start a sql profile to identify the creator of duplicate items - WILL DO & WILL REPORT BACK
ON ANOTHER NOTE ...
Could there be an issue with the ODBC Connection? I'm not exactly sure how to troubleshoot/correct this but is it possible the ODBC connection is still looking at the Prod A server?
Thanks Again for your help!
Theresa "Trez" Moreland
Maryland Dept of Budget & Mgt
OIT/EIS/Service Desk
Annapolis, MD
September 30, 2007 at 11:40 am
Trez,
Have you rechecked the odbc-connection?
Other things to check:
*select @@SERVERNAME /*internal name of server*/
*change the password/account used by the software account to connect to the development server (shouldn't hinder production).
*Is there replication set up between them?. Transaction replication is one-way, merge-replication can be two-way.
An odd programming situation can be:
It inserts a new item using connectionsetting A
It checks if the insert was succesfull using connection setting B and reinserts using setting B because the item wasn't there).
October 2, 2007 at 9:15 am
Hi Jo:
NO REPLICATION SET UP BETWEEN DEV & PRD
I rechecked the odbc-connection - it was pointing to the PRD server. I tried deleting it and creating a new one ... then I ran select @@SERVERNAME and PRD server name & data returned.
Then I ran sp_linkedservers and found that during the imaging a linked server relationship must have been established on both servers - pointing to PRD - deleted both of them.
Neither remedy helped my situation ... I may be doing something incorrectly... still researching.
Still working on checking programming - working with the application support team on that ...
Thanks again for your input!
Trez
Theresa "Trez" Moreland
Maryland Dept of Budget & Mgt
OIT/EIS/Service Desk
Annapolis, MD
October 2, 2007 at 10:17 am
*the @@Servername could still point to an older name, it doesn't autoadjust to the wins name.
at http://www.databasejournal.com/scripts/article.php/1496451
you can find a script that resets it to its wins name
sp_dropserver ...
sp_addserver ...
restart
*depending on network configuration
you could modify the hosts-file on the development machine
to get the productionserver in the non-routed area
196.168.0.5 myproductionserver.
http://www.pantz.org/networking/tcpip/subnetchart.shtml
*is there any delay between the mirroring (at regular intervals,...)?
*any chance that a DTS package or something is connecting by ip instead of using names?
October 3, 2007 at 11:19 am
Hi Jo:
Good news and bad.
Good news is problem resolved.
Bad news is - I've been chasing my tail because it wasn't a database issue after all - it was an applicaiton issue.
I've been banging my head against the wall for several days now because I couldn't figure out why the database & application were looking contuing to look at wrong server. I've been running API logs to see if any code was making API calls directly on the DEV server, checking applicaiton configuation settings on both machines, dropping & adding new ODBC connections, running application utilities, running database utilities - I even tried the script to rename the server that you suggested yesterday at http://www.databasejournal.com/scripts/article.php/1496451
- all to no end.
Yesterday I heard back from the Application MFG support team (I've had a ticket with them all along) and they finally suggested that I manually look at the application config file.
Apparently, after mirroring the machine - it wasn't enough to use the application to change the server name it looks at - I had to manually change the server name in the applicaiton config file - once I did that ... problem solved! I guess I should have known this ... won't ever forget that again! Trial by fire is the best way to learn, they say!
Anyway - I want to apologize for running you around in circles with me and thank you for all of your help. I've certainly learned a lot in these few short but dense days 😉 I now feel more comfortable with my database and have discovered a lot of interesting things I need to learn more about as a result of my "head banging." Thanks so much!
Trez
Theresa "Trez" Moreland
Maryland Dept of Budget & Mgt
OIT/EIS/Service Desk
Annapolis, MD
October 3, 2007 at 12:27 pm
you're welcome
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply