Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
So Monday has gotten off to a grand start. I came in and our Windchill was down and has been down since Saturday morning after Friday night's backup kicked off. The server manager was giving an error that it could not connect to our database. So I started to look at the database and there were no tables. Went over to our IT database person for help. He was finally able to see tables in the database. However when we did a properties on the database, the location and names of the database files was incorrect. It had switched everything from our 😧 and F: drive setup to C: drive, along with changing the names of the files. We started to dig a little further because we wanted to change them back and found that our test server was being pointed to and that the file names and paths corresponded with the database files on our test environment. We have been running in this environment for over 1-1/2 years without any issues. I have not updated SQL Server or Windows on either machine within the last few weeks to have caused something to happen. For now I have taken my test environment off of the network and when SQL was restarted on the production server, everything was pointing to the correct location.
We are on Windchill 10.2 M030 and SQL Server 2008 R2. Anyone have any ideas as to what to even look for? Anyone ever have this happen to them?
Sounds like a tough Monday. As some sort of prevention we have the Windchill service set up such that it is dependent on the particular MSSQL instance and so if the database instance goes missing Windchill service will shut down as well. I don't really know exactly how this is done, but if you manage to set it up then it might help.
We are running Windchill 10.2 M030 with MSSQL on Windows Server 2012 as the production server. We also got test server pointing to the second database instance on the production server, which makes things complicated when the test server needs to be updated/restored etc.
Thankfully Windchill wouldn't start because it couldn't connect to the correct database. But you could see the tables for the test database from SQL Manager on the production server. It was really slow and it didn't show them on the first time looking at the database.
I am just curious how a restart fixed the problem. Are you sharing your DB instance between test and production?
We shutdown the two test servers, which are virtual environments on their own server. Then the production SQL pointed back to the server it was located on with the path and name information correct. No, we are not sharing the DB between test and production. They are two separate servers, each with their own databases. In this current environment, we have had it up and running this way since September 2015 and this is the first time this has ever happened. For now we have the two test servers disconnected from the network to try and investigate to see if there were any changes on them. All this happened after our maintenance plan ran on the production SQL database.