The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
Service Desk Practitioners Forum
Showing results for 
Search instead for 
Did you mean: 

Clean SD database for new year

Senior Member

Clean SD database for new year

Hi all,

Scenario is like this:
SD began production in Jan '05. At the end of '05, a full back up of the SD db is performed.

Is it possible to have a clean SD db in terms of clearing all its '05 tickets(SC,incident,change,etc).

For eg, delete all the tickets but leaving the configuration of SD as it is.

But then again, deleting a ticket could cause quite a number of relation issues. Such as relation with workorders or SLA, etc.

If you create a new DB then all the configuration will be lost, unless there is a relatively easy/convenient method to 'map' the configuration into new db.

Other possible solutions, playing with the filters are one option but that doenst clear the jus limits one's view in the console.

Any thoughts on this?

Illya Lyfar
Regular Collector

Re: Clean SD database for new year

I think, you can try archieve your SC, incident, change (Administrator's Guide, Charter 11) - this operation clean your database).

Ramaprasad N
Esteemed Contributor

Re: Clean SD database for new year

Yes. It's better to archive all the required entities. This leaves your other data/configuration intact.

With ACES facility, you can export/import the OVSD configuration settings. However, all your CIs, Maintenance Contracts, SLAs, etc will have to be created again. Hence, it's better to archive the required elements and use the same DB FY'06.

Eric P_2
Senior Member

Re: Clean SD database for new year

Hi Ramaprasad,

I have tried the ACES Export, some datas cannot be exported (they said i do not priviledge to view). so i tried to reduce some datas to export. after finished exporting, i did ACeS Import to clean Service Desk. So many errors and warnings come up.. is it normal ?

or I just missed some procedures ?


Marc Hummel
Frequent Visitor

Re: Clean SD database for new year


Create views that filter on what you want to get rid of. Use these views for archiving. simple.

Archiving, pulls out of cmdb and exports to xml file, one caviat I can think of off the top of my head is that the attachments belonging to these archived SC's will also be removed from the cmdb. once you archive you really shouldn't plan on retrieving, it is for historic records and will be a major effort to restore.

Wounds heel, Pain fades... chix dig scar's, oh and everybody WangChung.
Robby De Naeyer
Regular Collector

Re: Clean SD database for new year


My advice as an OVSD consultant to all of my customers is only to start removing (read archiving) service desk items after two years.
So with my customers we start archiving all service calls, incidents, work orders, â ¦ from the year 2004.

You may want to keep last yearâ s data in your environment for reporting purpose, as a resource for future incidents and as an educational source for new team members.
The only reason in my opinion for removing last yearâ s data would be usefully for reducing your database size.

As you already noticed deleting the items is not an interesting way of removing the data from your service desk environment because of the many relations.

Copying your configuration and data from your existing environment to a newly installed empty database does not offer any added value to your new environment.
Restarting with a new environment would only reset database object IDâ s and the service desk data IDâ s.
Nevertheless if you would like to use this approach you need to keep in mind that by using the aces feature you still need to respect the relations between your data.
(e.g.: you can not apply a db rule on a field that does not yet exist)

Archiving your service desk data would be the most efficient way of removing data from your service desk environment. This feature does not require you to keep in mind the different relations between the data.

In theory you could restore the archived data but as Marc Hummel already stated there is no easy way to retrieve the data. So if you need to consult the removed data it is better to restore your last database dump in a testing environment.

Eric P_2
Senior Member

Re: Clean SD database for new year

Dear All,

Does this archive feature reset the Servicall call ID ?

Robby De Naeyer
Regular Collector

Re: Clean SD database for new year


No it does not reset the id's used in service desk.

Archiving only removes the selected dat from the database and stores it in an XML file.

Best regards,
Robby De Naeyer.
//Add this to "OnDomLoad" event