Now I have a clearer picture of what you are trying to do... The key to your success will be in understanding the underlying data dictionary (not in the traditional sense either). You will need some help in this area. You may want to ask Joe D. for help.
1. ITSM is very complex system and difficult to archive. Most folks just run one instance and when a new version comes out - they cut over completely and just import the Foundation data. The more modules you use the more complex the archiving strategy. 2. BMC could have simplified archiving for us if they would have allowed archiving forms to be used between servers. 3. You are going to have to first decide what pieces of data you would like to keep. For example if you were going to keep Incidents - you would have to know what associated elements are required to show incidents for example: - Attachments - Impacted Areas - Associations - Work Logs - Etc.... I guess - the rule of thumb - would be to look at the table fields that display data for the key forms in the modules and make sure that data is brought over. 4. You will then have to deal with the issue of workflow. If these are archived records - all you want to do is view the data and not modify; therefore, you would want to lock down the forms(all fields read only) and disable workflow that would allow modifications. 5. When it comes to licensing - you should check with your local Remedy Sales person. The licensing model is constantly changing - they may have something reasonable once they are aware of your needs. My suggestion though would be to stress that you need read only licenses, since you will never modify any data. 6. Well since you don't have a lot of data - I think you could really leverage DSO to sync your Archive server. Again - you will want to be careful about how much and what you archive. If you try to archive the whole ITSM Suite - I think you will not have much luck. 7. Remember Archive Forms must exist on the same server. You cannot use Archive forms between servers. Once you have the data in the Archive forms - you are going to have to come up with a Strategy that will help you move the data from the Archive forms to the new Archive Box. Naturally, you will also need a mechanism to remove the old entries off the Archive Box. I suppose you could use DSO to do this part. 8. The frequency of archiving - will have to be yours to determine. I usually - look at the rate of record accumulation. I would look at the tables that I want to archive and determine their rate of growth - then archive according to how much data you want to have in your Production tables. Unfortunately, I do not have any documents specific to this - I have found that for the most part - I have to determine what needs to be done - then draw up strategy that can be documented for the specific case. Then there is the issue of what technologies to use? On Feb 15, 2:57 pm, Hari Vishwakarma <[email protected]> wrote: > Hi All, > @Allen, > Thanks for your valuable suggestions. But out of the available options, i > think i need to choose the best otherwise i will be playing with fire. > > I am looking to archive the data in the following way: > > 1. Selective archiving( with conditions such as all the tickets which are > closed by the system, cancelled tickets with work logs,attachments), but > here full archiving of data is also open and in mind. > 2. As far as archived data is concerned, we will be using that data for > reporting as well as for audit purpose. > 3.We are ready to stand up another instance of remedy(But not sure about > the licensing terms of BMC like AR server license,ITSM Apps > license,Database license.) > 4.We have implemented Remedy in our company four months back,so data is not > so huge, but as the time passes on, it will grow further.So, can you > suggest what frequency should we adopt for archiving(like daily, > weekly,monthly) > 5.Initially i am thinking of using DSO,but seems it is complex, so i am > going for archive forms. While archiving, i want to move the data > completely to newly created remedy instance which will reduce the load on > the production and can be used for reporting purpose on the newly created > remedy instance. On production, only the current data will resides like 3-4 > months old data. > > I also request you to share any document which will guide me step by step > approach or plan, which will help me to achieve the required goal. > > Guidance is always a ray of light to eliminate the darkness of ignorance. > > With a smiling face > > Regards > > Hari > > > > > > > > > > On Tue, Feb 14, 2012 at 8:23 PM, Elry <[email protected]> wrote: > > Hey Hari... > > > Some quick opinions : > > > 1. Looks like you will be doing selective archiving & not fixed > > archiving. What this means for us is that you will be selecting > > criteria for tickets that will be archived as opposed to archiving all > > tickets for a fixed time period. This means that you will have to > > make multiple passes during each archive transaction to get older > > tickets. > > 2. If you are going to close tickets - then you will probably want to > > get all the data associated with the ticket (i.e. work logs, > > attachments etc.). > > 3. You have to decide whether or not you want to use the same Remedy > > interface to look at and retrieve the archived data (you could just > > rely on reports). > > 4. If you use the Remedy interface then - you will have to stand up > > another Remedy instance (granted - that there will be only viewing of > > data - so there will not be a need for write licenses). > > 5. Frequency of archiving, and server performance will depend on how > > much data you will be moving. > > 6. DSO may not be the best method for data migration. > > 7. If you use archive forms - note that the archive forms must be on > > the same server as your Remedy instance (this still leaves your data > > on your production box). > > 8. Remedy Migrator is another option (if you can afford it). You are > > able to configure private TCP ports to help reduce the load on the > > server. Only drawback - it does not look like there is a way to delete > > your record after archiving; therefore, this will have to be an > > escalation or some other workflow. > > 9. In the past I have used EIE OR AIE OR AI - not sure what they are > > calling it now. This works ok, but it's newest incarnation that > > leverages the Pentaho Spoon ETL engine looks to be superior (I think > > you need version 7.6.04 of ITSM). > > > There are third party options like (rrchive is free and picks up where > > the Migrator left off): > > > META-UPDATE:http://www.softwaretoolhouse.com/product/SthMupd/index.html > > RRCHIVE: http://www.rrr.se/en/ > > > On Feb 14, 8:31 am, Hari Vishwakarma <[email protected]> wrote: > > > Hi, > > > > We are planning to have archiving server with the following strategies > > in place: > > > > 1. We will be moving our production server data to the newly created > > > archiving server with certain conditions like incident=closed or > > > cancelled, and we will be archiving the data on an interval of 2-3 > > > months. > > > > Here, i have few queries: > > > a.Will this archival server requires any new hardware,os,remedy ars, > > > remedy apps, licenses. > > > Plz note that my current remedy environment is on windows 2003 server, > > sql serv > > > er 2005 database,ARS 7.5.04,remedy ITSM apps7.6.01 > > > b. Can this archival server be synched on an database level, if yes then > > how? > > > > 2. what frequency shall we use to archive the data from the production? > > > > 3. will this hamper my production server performance? > > > > 4. We are planning to use archiving forms or DSO, please suggest its > > > pros & cons while implementing. > > > > Please suggest . > > > > Regards > > > > Hari > > > > One more thing, how this movement of data will happen even after > > > 1.We want our production data to be moved from production to archival se > > > > On Tue, Feb 14, 2012 at 1:17 AM, Elry <[email protected]> wrote: > > > > > Well Hari... > > > > > We currently just finishing up the creation of an archival server. > > > > > I guess my key questions would be: > > > > > 1. Do you have any Archive Policies in place (i.e. Incident Tickets > > > > will be automatically closed after 90 Days). > > > > 2. What applications are you running (i.e. ITSM or Custom > > > > Applications)? > > > > 3. What do you want to archive? > > > > 4. How are you going to archive (Archive forms, DSO, Remedy Migrator, > > > > DRIVER.EXE, etc.)? > > > > > On Feb 13, 1:32 pm, Hari Vishwakarma <[email protected]> wrote: > > > > > Hi All, > > > > > > I want to create an archival server which will offload my production > > server > > > > > load & improves my production server performance > > > > > Can anyone suggest what are all the prerequisites for the required > > archival > > > > > server.And what need to be kept in mind while configuring this. Also > > will > > > > > it require any short of customizations for achieveing an archival > > server. > > > > > > Please suggest to achieve the same. > > > > > > -- > > > > > Best Regards, > > > > > > Hari shankar Vishwakarma > > > > > Mobile:- +91-9833675872 > > > > > E-mail:- [email protected] > > > ___________________________________________________________________________ > > ____ > > > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > > > attend wwrug12www.wwrug12.comARSList:"Where the Answers Are" > > > ___________________________________________________________________________ > > ____ > > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > > attend wwrug12www.wwrug12.comARSList:"Where the Answers Are" > > > ___________________________________________________________________________ > > ____ > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > attend wwrug12www.wwrug12.comARSList:"Where the Answers Are" > > > ___________________________________________________________________________ > > ____ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" > > -- > Best Regards, > > Hari shankar Vishwakarma > Mobile:- +91-9833675872 > E-mail:- [email protected] > > ___________________________________________________________________________ > ____ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
