Showing posts with label old. Show all posts
Showing posts with label old. Show all posts

Monday, March 12, 2012

Is there equivalent to Sybase Dynamic Archiving for SQL Server

Sybase has a product called Dynamic Archiving which will automatically move
old records to a archive database, but all applications will see the two
database as one (no changes to source code etc.)
Is there an equivalent for SQL Server (either now, or part of 2005, or third
party) ?
Any help would be appreciated...
Regards,
Mark Donoghue
MDonoghue@.refco.comI'm not aware of anything identical.
In SQL2K... you might be able to achieve a similiar effect by looking at
Partioned Views. Not real archiving, but you might get some of the benefits
you're looking for. Stricktly a roll your own solution.
SQL2005 adds support for partioned ranges (using multiple tables) that will
make it much easier to manage this. But still roll your own.
--
"Mark Donoghue" <MarkDonoghue@.discussions.microsoft.com> wrote in message
news:A27078A5-CD17-46C1-8DD1-AA9DA6002730@.microsoft.com...
> Sybase has a product called Dynamic Archiving which will automatically
move
> old records to a archive database, but all applications will see the two
> database as one (no changes to source code etc.)
> Is there an equivalent for SQL Server (either now, or part of 2005, or
third
> party) ?
> Any help would be appreciated...
> Regards,
> Mark Donoghue
> MDonoghue@.refco.com

Friday, March 9, 2012

Is there anyway to tell when a database was last accessed or changed?

Is there a simple way to tell when a database was last accessed or changed?

We have some databases on old servers which we would like to discontinue but do not know if they are being used.

We would rather not just take them offline.

Is there anyway I can find out if they are still being used?

Please help if you can.

Regards, Major (that is my Christian name ;-)

I've run into this problem a few times. The best way I have found to deal with this is to set up a trace on the databases for reasonalbe period of time. With the trace, you should be able to see who accessed what, when, and with what application. This info can be helpful in determining how the database is being used in your organization.

The difficult part is to determine what constitutes a reasonable period of time. Some business groups access some databases on monthly, some on quarterly, and others on annual cycles. Other databases are used upon occurance of special events such as an audit or a lawsuit.

So, in addition to the trace, you may want to send out a survey asking for users to step forward. You will also want to be certain to take a few good backups and be able to access them very quickly should a user step forward after the database has been decommissioned.

Finally, get approval of higher-ups before dropping the database. This just helps spread the blame should someone in the business get upset.

Good luck,
Bryan

|||

Adding on to Bryan's comments, when the decision is finally made, I normally just take the databases 'off-line' for a period of time. Then if something breaks, it is quick and easy to put the database back online. (I've been know to keep databases in 'off-line' mode up to a year before completely removing them from the server.

Even with backups, when some upper level 'suit' is put out because the special use database isn't available and he must have a report in a hour, it is a boon to quickly revert to on-line status and say 'oops'.