|
|
Posted by BD on 09/21/06 17:13
Hi there.
I'm on a SQL 2000 SP4 machine.
This is a development machine, with only a couple of small databases on
it.
Yesterday I needed to recover a table from backup, so I went through
the following process:
-Used 'Create SQL script' to generate a create db statement from the
current db.
-Changed the db name, and all file paths to not conflict with the
current db.
-Created a new db in a new directory with this script.
-Restored last night's backup from the 'real' db to the new one.
-Went into the 'recovered' database, located the table which needed to
be restored, and renamed it to "<table_name>_RECOVER"
-Used DTS to transfer that table to the 'real' database
-Truncated the table to be recovered
-did a 'Insert into select * from' statement to recover the records.
-dropped the table that I had copied in via DTS. This table was small -
8000 rows or so.
The database seemed fine at the time.
Now (the next morning) I am finding that performance of the 'real'
database is agonizingly slow. Even doing a 'select count (*) from <a
small table> simply does not return a result. the 'processing' globe
icon spins merrily away, and I get no result set.
However, the same query, submitted against the 'recovered' database
(the one I restored in order to get the data I required) responds
instantly, as it should.
These databases are both hanging off the same named instance of this
server (there are three instances).
A quick Perfmon check shows the CPU to be nearly idle.
I'm not sure what to look at here - can anyone suggest a direction?
Thanks!
Navigation:
[Reply to this message]
|