[dba-SQLServer] Problems registering database

Well, I spoke too soon.  Now Neo2 is pegging the CPU usage all the time, and
EM can't even get in to it's own database (local).  Or more correctly it can
see the db but when I try and click on databases it just hangs with the
hourglass.  Which is a catastrophe!  Before I could at least use Neo2 from
Neo2, now I can't do anything at all.

Come to think of it, it may be trying in vain to roll back a transaction or
something.  I had QA running an update query when I changed the login type
property which forcefully shut down SQL Server.

I think I'll go to bed and pray that this thing survives.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of John W.
Colby
Sent: Monday, October 11, 2004 11:43 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Problems registering database


Andrew,

Well, halafrigginlula.  On Soltek1 I tried to register Neo1 and Neo2, using
sa and the password.  Neo2 registered correctly, Neo1 gives me a "login
failed for user sa".  Likewise, on Neo1 I registered Neo2 using sa and the
password.  Soltek1 was already registered.  My laptop ColbyM6805 registered
Neo2 using sa and the password but the registration of Neo1 and Soltek
failed. From my wife's machine MaryDesktop I can see all the other servers
but only Neo2 registered successfully.  Neo1 and Soltek1 failed with the
"login failed for user sa" and M6805 failed with the infamous "guest".

In fact this gets me 1/2 way there since the nVLDB physically resides on
Neo2, I can now bang at it from Neo1, Soltek1, MaryDesktop and my Laptop.  I
am definitely thrilled at the improvement in my situation however I'm also
very uneasy that I have no clue why this "X registers but Y fails" is going
on.

I also tried to use the property dialog of the local laptop on my laptop to
set the startup service to sa and oh man what a mistake THAT was.  Now I
can't get the local database to login at all.  It tells me the login is
broken or something (so true! 8(

I can't get at the property dialog, I can't start the service manager,
basically I am really hosed on that machine.  Which is a problem since a
database for a project I am working on is on that machine.  Sigh.

So any ideas how do I get back in to this database?

Any ideas why the sa account works on Neo2 but not on Neo1 or Soltek1?

Is there any way to just look at all the accounts like you can in Windows?
If I could do that I might be able to compare machine to machine and see
what the heck is going on here.  AFAIK I just told it the default install of
SQL Server so I just don't understand why the responses are so different
from machine to machine.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Haslett,
Andrew
Sent: Monday, October 11, 2004 10:45 PM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Problems registering database


You did it all correctly except the account isn't 'administrator', its
actually just 'sa' (which stands for system administrator).  So the username
is actually sa and the password is what you specified.

The security risks you speak of are correct, as the sa account has full
rights over the entire instance of SQL Server you are using, which you often
don't require - however if you were to use Windows Auth, you'd still need to
set up the login and access permissions for *an* account in SQL itself for
it to work.

Therefore whichever way you go, you'd still have to learn about logins /
roles / security etc. and from what I understand of your requirements, you
don't have time to learn or master this.

Therefore, the sa account is the easiest for you to setup and use, as it
will require no configuration of account / security etc -> and as (I think)
you're on a (relatively) isolated network with hardware, software firewall /
NAT etc., the security risks are no more severe than if someone hacked into
your machine anyway.

Cheers,
A


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com