Dialup Dead - Slammered again?

realraven2000@.hotmail.com wrote:
> any idea what to do, did I miss a new patch / virus?
> Axel
>
Since you can connect with QA, you should be able to run sp_who2 or look
at the sysprocesses table. Attempt your EM connection again, and while
it's spinning, jump into QA and look at sysprocesses to see what's
running. Look for blocking, or some other intensive process that might
be running.HI I am trying to logon to a remote server with Enterprise Manager via
dialup, which worked fine for the last 6 months. I can connect to the
server but Now I am getting the egg timer for ever when expanding the
database node. At the same time my dialup maxes out (around 3 kB / sec)
and seems to load ridiculous amounts of data (by dialup standards x-p).
I have SP4 installed, is this a new version of Slammer or what?
PS: I can connect with Query Analyzer and run queries. My version
number is 8.00.2039 (SP 4).
any idea what to do, did I miss a new patch / virus?
Axel|||realraven2000@.hotmail.com wrote:
> any idea what to do, did I miss a new patch / virus?
> Axel
>
Since you can connect with QA, you should be able to run sp_who2 or look
at the sysprocesses table. Attempt your EM connection again, and while
it's spinning, jump into QA and look at sysprocesses to see what's
running. Look for blocking, or some other intensive process that might
be running.

Dialup Dead - Slammered again?

HI I am trying to logon to a remote server with Enterprise Manager via
dialup, which worked fine for the last 6 months. I can connect to the
server but Now I am getting the egg timer for ever when expanding the
database node. At the same time my dialup maxes out (around 3 kB / sec)
and seems to load ridiculous amounts of data (by dialup standards x-p).
I have SP4 installed, is this a new version of Slammer or what?
PS: I can connect with Query Analyzer and run queries. My version
number is 8.00.2039 (SP 4).
any idea what to do, did I miss a new patch / virus?
Axelrealraven2000@.hotmail.com wrote:
> any idea what to do, did I miss a new patch / virus?
> Axel
>
Since you can connect with QA, you should be able to run sp_who2 or look
at the sysprocesses table. Attempt your EM connection again, and while
it's spinning, jump into QA and look at sysprocesses to see what's
running. Look for blocking, or some other intensive process that might
be running.

Device activation error problem, Index file missing

Hi, everybody.
I have a big problem. One of the disks in RAID 5 array went dead, and
our costumer's administrator tried to fix the problem, which he did, in
the end, but thet ment that all the data on that partition was lost. A
great way to fix the problem, don't you think? Unfortunately, on that
partition there was Index_data.ndf, file that I used for all the
indexes in my database, all the data is in the other file, on the other
partition. There's no backup bacause the database size is about 500GB:(
Now, database is in suspect mode, of course, and I'm thinking about my
options. I know there's a way to put database back from suspect mode
and transport the data using DTS or something to another db, but I'd
really love to skip the part where I get to transport manually 300 GB
of data from one db to another.
What I want to know is this: is there a way to delete indexes from
tables in database, or to delete the index file from database
properties so I could start database again, recreate index file and
recreate indexes?
Any halp is appreciated...
Regards,
MarkoOf course database size does not deteremine backups. Have them buy idera or
redgate. I backed up a 600GB DB to 20GB file with both, no fuss no muss.
On to your problem. Is this 2000? You can reset the suspect flag with
sp_resetstatus. Barring any other options, I would use that proc and then
try to get a backup even if you have to download red-gates eval tool. If you
have a good backup, attempt to drop all indexes located on the now missing
partition by generating a script or turning on ad-hoc updates to system
tables(2k only) and attempting to drop them from there(sysindexes). if you
can't get a reliable backup(ensure you can restore it before doing anything
permanent) once you have the db out of suspect mode, you might have to force
table scans wth queries to get data out as the missing indexes could play
hell with the optimizer and any tool you choose. Red-gate's suite may also
help here, saving you some legwork.
Lastly, slap the admin.
"Marko.Sunjic@.gmail.com" wrote:
> Hi, everybody.
> I have a big problem. One of the disks in RAID 5 array went dead, and
> our costumer's administrator tried to fix the problem, which he did, in
> the end, but thet ment that all the data on that partition was lost. A
> great way to fix the problem, don't you think? Unfortunately, on that
> partition there was Index_data.ndf, file that I used for all the
> indexes in my database, all the data is in the other file, on the other
> partition. There's no backup bacause the database size is about 500GB:(
> Now, database is in suspect mode, of course, and I'm thinking about my
> options. I know there's a way to put database back from suspect mode
> and transport the data using DTS or something to another db, but I'd
> really love to skip the part where I get to transport manually 300 GB
> of data from one db to another.
> What I want to know is this: is there a way to delete indexes from
> tables in database, or to delete the index file from database
> properties so I could start database again, recreate index file and
> recreate indexes?
> Any halp is appreciated...
> Regards,
> Marko
>