One question. Why do you want archiving to take place on a different server?
I mean, the archived tables can reside on the same database engine. It's up to the dba to tune the database and place those table on a different volume. Regards, Jose Huerta http://theremedyforit.com/ On Thu, Feb 16, 2012 at 20:06, Hari Vishwakarma <[email protected]>wrote: > ** 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] > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
