Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
sqadil
Starting Member
11 Posts |
Posted - 2009-08-13 : 08:34:09
|
When and how msdb database will be helpfull |
|
yash8506
Starting Member
6 Posts |
Posted - 2009-08-13 : 08:46:36
|
When you want to restore DTS then you should have backup of MSDB. |
|
|
EMarkM
Starting Member
16 Posts |
Posted - 2009-08-13 : 11:01:40
|
The msdb database is used by SQL Server Agent for scheduling alerts and jobs. |
|
|
sqadil
Starting Member
11 Posts |
Posted - 2009-08-14 : 06:53:48
|
Thanx to you all..n any suggestion to improve the performace of DTS...? |
|
|
EMarkM
Starting Member
16 Posts |
Posted - 2009-08-14 : 11:12:53
|
Improving the performance of DTS can be achieved by a number of things: it would help if you could be more specific about the problem. Likely causes of poor performance would be the usual candidates: inefficient SQL queries in the package, network issues, hardware issues such as memory and CPU.In order to get closer to the truth, you need to isolate some of these factors by running queries on their own, examining query plans and SQL Profiler, doing other tests for network and yet more for server/client hardware issues.Give us as much detail as you can, and we'll try to help. |
|
|
sqadil
Starting Member
11 Posts |
Posted - 2009-08-17 : 03:09:56
|
ok.. here u go,A datawarehouse module is built to support one of the modules of our project and all of it through DTS. This module is running everymonth end to generate some reports. We call it a batch. and this batch-run isrunning from years, recently it took 30+ hrs [usually 20+].. So now I have to finetune this.. and is urgent.all this happening in production environment n don have direct access to it. Can work only on dev server |
|
|
EMarkM
Starting Member
16 Posts |
Posted - 2009-08-17 : 10:14:40
|
As I said before, you need to break the problem down into the various elements I described above, to see what aspect of the package is actually causing the problem.With a sudden increase in time like this, I might be looking at a recent database size increase, number of databases/servers being contacted by the package, contention around when the scheduled job actually runs, and the fragmentation of indexes and so-on.From a hardware point of view, are your network and network interface cards definitely working like they used to?Hope this gives you a starting point. |
|
|
|
|
|
|
|