Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

RDS.EXE - Problem 1

Status
Not open for further replies.

nvhusker

IS-IT--Management
Feb 7, 2006
14
0
0
US
Hey all, we are currently running v11.1 of Brightstor Backup and we noticed a service that is running on our server called rds.exe and it seems to take up quite a bit of memory. The reason we were looking into this was because whenever we have to do a restore and we try and "drill-down" through the sessions to find what we want to restore, it takes painfully forever to do this. We click on a session and it can take 2-3 minutes before it even expands the session.

We did a search on the internet and found some reference to the rds.exe as a virus. As we ultimately found out, Arcserv Brightstor uses this service for their database. "Raima Database Service".

Okay, no virus, but still slow. Could this just be a hardware issue? Is there any way to clean up the brightstor database to make it respond faster? Any help on this would make my life extremely better! Thanks all.
 
Thanks for the link to the document. It seems we will need to run the command-line utilities to resolve this issue. Is there any information on how long these jobs will take to run based on the size of your database? Thanks again.
 
No, as per the document there is no approximation you can make.
 
If you have a large database, (like, for example, ASTPSDAT.000 is 1-2 GB or bigger) then it will take for frickin' ever to do a defrag and keybuild, even on a 3GHz Xeon processor server. The processes run on one processor and don't use enough threads to take advantage of any speed, and at most you can use 1000 64K buffers for the command, so most of the RAM goes to waste.

It's faster, sometimes, to reinitialize the database and re-merge the tapes back in.

I'm sure the database engine can be tuned better than what comes "canned" from CA, but they don't tell you squat.
 
They don't tell you 'squat' because it isn't their database, it is a third-party 'run-time' database provided by Birdstep, ex-velocis, ex-raima.
 
init and merge is definately faster. If the utils are run once every week or two they go faster but still the larger that database gets the slower it will be, and that is not use it takes longer but it will actually run slower. After all it has not been updated in around 5 years and the fact that the only repair utilities are command line.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top