Hi All, @Allen,
Thanks Allen for your well guided and motivated approach.I will keep all suggestions in mind and accordingly implement the same. Thanks & Regards Hari [email protected] +91-9923490040 On Thu, Feb 16, 2012 at 10:58 PM, Elry <[email protected]> wrote: > 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" > -- Best Regards, Hari shankar Vishwakarma Mobile:- +91-9833675872 E-mail:- [email protected] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
