January 13, 2009 at 1:24 pm
We have a domain that is getting out dated and isn't necessary. So our plan was to migrate the system to our main domain. This is a Windows 2000 server with SQL 2000 Enterprise edition. We thought things were working ok. Things were working as far as the application and then we tried to open Enterprise Manager. SQL locks up then. You can use query analyzer up until someone open Enterprise Manager. Also, if you start the sql service, you can't stop it without just rebooting the machine. We didn't change the services username and password in Enterprise Manager but just changed it on the service. In my fumbling on the internet, it looks like you have to check some security for some folders and registry keys. I added full access to the ones that looked like they needed it but still no dice. Any advice would be greatly appreciated. Thanks
January 13, 2009 at 1:42 pm
What accounts are running SQL? I might change them to LocalService and then back again with EM to reset permissions.
January 14, 2009 at 6:12 am
I set both services to be run by local. Logging into EM is the problem. That is what causes it to crash. So I can't change anything in there. I can user query analyzer however. At least until we open EM 🙂
January 14, 2009 at 6:39 am
Anyone who says buggured up automatically get's my attention.
Curious as to whether there are any pointers in the event logs, or the SQL logs that might indicate some kind of issue.
January 14, 2009 at 7:06 am
Nicholas Cain (1/14/2009)
Anyone who says buggured up automatically get's my attention.Curious as to whether there are any pointers in the event logs, or the SQL logs that might indicate some kind of issue.
Here is the log:
2009-01-14 08:55:24.25 server Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
2009-01-14 08:55:24.25 server Copyright (C) 1988-2002 Microsoft Corporation.
2009-01-14 08:55:24.25 server All rights reserved.
2009-01-14 08:55:24.25 server Server Process ID is 2156.
2009-01-14 08:55:24.25 server Logging SQL Server messages in file 'e:\MSSQL\log\ERRORLOG'.
2009-01-14 08:55:24.30 server SQL Server is starting at priority class 'normal'(4 CPUs detected).
2009-01-14 08:55:24.78 server SQL Server configured for thread mode processing.
2009-01-14 08:55:24.89 server Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner Blocks.
2009-01-14 08:55:25.44 server Attempting to initialize Distributed Transaction Coordinator.
2009-01-14 08:55:28.27 spid1 Starting up database 'master'.
2009-01-14 08:55:28.83 server Using 'SSNETLIB.DLL' version '8.0.2039'.
2009-01-14 08:55:28.83 spid5 Starting up database 'model'.
2009-01-14 08:55:28.83 spid1 Server name is 'THPFDATA'.
2009-01-14 08:55:28.85 spid8 Starting up database 'msdb'.
2009-01-14 08:55:28.85 spid9 Starting up database 'pubs'.
2009-01-14 08:55:28.85 spid10 Starting up database 'Northwind'.
2009-01-14 08:55:28.85 spid11 Starting up database 'audit'.
2009-01-14 08:55:28.85 spid12 Starting up database 'cabinet'.
2009-01-14 08:55:28.85 spid13 Starting up database 'his'.
2009-01-14 08:55:28.85 spid14 Starting up database 'wfe'.
2009-01-14 08:55:28.85 spid15 Starting up database 'HBF'.
2009-01-14 08:55:28.85 spid16 Starting up database 'eiwdata'.
2009-01-14 08:55:28.85 spid17 Starting up database 'EIS'.
2009-01-14 08:55:28.85 spid18 Starting up database 'DBA'.
2009-01-14 08:55:28.97 spid5 Clearing tempdb database.
2009-01-14 08:55:28.99 spid16 Analysis of database 'eiwdata' (12) is 100% complete (approximately 0 more seconds)
2009-01-14 08:55:29.02 spid11 Analysis of database 'audit' (7) is 100% complete (approximately 0 more seconds)
2009-01-14 08:55:29.07 server SQL server listening on 10.32.16.125: 1433.
2009-01-14 08:55:29.07 server SQL server listening on 127.0.0.1: 1433.
2009-01-14 08:55:29.39 server SQL server listening on TCP, Shared Memory, Named Pipes.
2009-01-14 08:55:29.39 server SQL Server is ready for client connections
2009-01-14 08:55:29.44 spid5 Starting up database 'tempdb'.
2009-01-14 08:55:30.22 spid12 Analysis of database 'cabinet' (8) is 100% complete (approximately 0 more seconds)
2009-01-14 08:55:51.49 spid1 Recovery complete.
2009-01-14 08:55:51.50 spid1 SQL global counter collection task is created.
Nothing else gets written to the log after that if I just try to open EM. It just hangs SQL and I have to restart to get the service stopped.
January 14, 2009 at 7:36 am
That's clean enough, what about in the event log? Are there any LsaSrv entries in the system log?
January 14, 2009 at 7:56 am
Did you try to unregister the server in EM and make a new server registration ?
[font="Verdana"]Markus Bohse[/font]
January 14, 2009 at 8:21 am
Nicholas Cain (1/14/2009)
That's clean enough, what about in the event log? Are there any LsaSrv entries in the system log?
Not that I have found. 🙁
MarkusB (1/14/2009)
Did you try to unregister the server in EM and make a new server registration ?
Yes. We have tried this serveral times because when you click on it to open, the status bar says something like:
Establishing connection to SQL Server and checking Windows security...
That of course made us think of windows accounts. So we unregistered and registered the server using the sa sql user just to make sure. Still has the same results. It doesn't say the "and checking Windows security..." part after we do the unregister and register. Just the "Establishing connection to SQL Server". So we would think that we are sure we aren't attempting to log in as a windows domain user. It doesn't matter if you are local or remote when you start EM either. Even trying to open the instance in EM on a remote machine has the same results and you have to End Task to kill it. Then we have to reboot to get it to stop the SQL service.
January 14, 2009 at 12:58 pm
I work with Jason and we just ran a profiler trace to grab everything possible when we try to open the instance through EM. What we see just as SQL hangs is exec Audit Object Permission Event - sp_MSgetversion - EventSubClass 1 - Bailout. We tried running this in query analyzer after a reboot and got the same results - hung SQL. Neither one of us are terribly proficient at reading profiler output. Any ideas? :crazy:
January 14, 2009 at 5:24 pm
Crack open the proc and see what its up to. That's always fun to be fair 😀
January 15, 2009 at 5:42 am
Check and see if there is a duplicate entry within active directory for the physical server that you are running on.
You could also try renaming your server.
January 15, 2009 at 8:20 am
Nicholas Cain (1/14/2009)
Crack open the proc and see what its up to. That's always fun to be fair 😀
We tried scripting this sp from a different instance but all we get returned is: There is no action to be scripted.
January 15, 2009 at 8:40 am
I took a looksee and it calls a DLL on the system.
First thing is check for the duplicate account in active directory.
Second, you could try copying that DLL from another system on to this one and see if that resolves the issue (XPSTAR.DLL it should be in the MSSQL\Binn folder, rename the existing before copying the new one, cos you never know)
Thrid would be to reapply Service Pack 4 (backing up all the databases beforehand just in case).
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply