Re: Export outgoing email to a file and attached to the ticket
If you are running ITSM check the Email Function from and Incident. OOB code takes the email and writes it into a Work Info record. You could look at that workflow to start with. The message is simply concatenated into the Work Info details so that may not be the actual results but the foundation is in place at least. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of clemence Sent: Thursday, December 18, 2014 8:10 PM To: arslist@ARSLIST.ORG Subject: Re: Export outgoing email to a file and attached to the ticket ** Dear All thank you for all your suggestion. I believe ican figure out how to make it work now Clemence On Thursday, December 18, 2014 5:01:52 PM UTC+8, clemence wrote: ** I've received a request from Business user whether for a particular outgoing email (we are using SMTP gateway for outgoing email), remedy is able to save a copy of the mail in msg format (incude sender email, recipient email, email content, attachment etc) and then attached this msg file to the respective ticket. any one got any idea how this can be done ? thanks Clemence _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
Hi Scott, We have a large Custom-Only installation – no ITSM or any other OOTB apps, thus – ARS only. I suggest not to skip the x or x.y major versions of the base AR System. The x.y.z minor versions generally do not have a notable design change on the DB – with the exception of 7.6.04, which introduced overlays (Don’t understand why BMC did not release this as a Major version???). This comes out of previous experience with having been called in to “fix” a number of failed upgrades in the past, amplified by a recent round of failed upgrade attempts. You could try to skip one or two of these versions – that’s up to you – YMMD – but no guarantees. You might be lucky when going directly from 7.0.1 to 8.1…. but I would not advise doing it to your Prod environment before doing some extensive testing on a duplicate test bed environment. We had the before-last round of upgrade attempts directly from 7.1.0 to 7.6.04 fail repeatedly on colleagues, a local support vendor and myself. We were desperate to get to a currently supported version of ARS, so I decided not to give up and find out why it fails….. Eventually got it sorted out safely using the steps I outlined before. We decided not to go to 8.0 or 8.1 as 7.6.04 is the last version that is shipped with the User Tool. Our user base are still making extensive use of the User tool and are reluctant to use Mid-Tier because of it’s lack of performance and because of the limitations it imposes on you as opposed to the User Tool. I would suggest using the ARS upgrade path with each of the versions I mentioned as I outlined it in my previous mail, (however you might want to upgrade to ARS 7.1.0 first), just to be on the safe side, because it is known to work that way. A single ARS Base upgrade does not take very long. We had a Saturday morning and afternoon change window to do the ARS Base upgrade from 7.1 to 7.6.04 SP5 and that was enough time to get it done. As far as the OOTB modules are concerned, I have not yet tried to use the 7.x ITSM modules on the 8.x AR Server, but logic dictates that it should still work if the 7.x ITSM libraries are still intact after the ARS upgrade, as the ARS API is backwards compatible. HTH. Best Regards, Theo From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Scott Hallenger Sent: 18 December 2014 18:41 To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path ** Theo.. was this an ARS upgrade only, or were you upgrading the whole ITSM suite. I'm looking into an upgrading of only my ARS 7.0.01 base, which has ITSM running on top of it, to to 8.1 or 7.6. We would leave the ITSM portion as is for now. Are you saying to do this we need to install every version of ARS until we get to 8.1 On Monday, December 15, 2014 2:11 PM, Theo Fondse (GMail) theo.fon...@gmail.com mailto:theo.fon...@gmail.com wrote: ** Hi Carina, We upgraded our Custom-Only 7.1/10g/Slolaris server recently to 7.6.4/11g/RedHat. I always suggest NOT to skip a major version when doing an upgrade, due to the fact that BMC only supports the last 3 versions, and therefore, might not test their software during development for upgrades from unsupported versions at the time. (I seriously doubt that BMC would have tested a straight upgrade from 7.1 to 7.6.04 or much less 8.0 or 8.1, due to their version support policies). Before I started my current stint at the company where I am working now, they attempted an upgrade from 7.1 to 7.6.4 and failed several times. Even with the assistance of a local support partner, the upgrade failed and they eventually gave up. The solution to the problem later turned out to be that you should not skip any major versions and go through the installer logs to find out what went wrong if the installer fails. We found a caveat with some of the AR System forms and tables which had to be addressed manually before the upgrade in order to get the upgrade to work. I suggest the following steps which worked for us to do a successful upgrade (please test it first on a development/test environment before doing this on prod): 1. Back up the current DB (full DB export dump). 2. Export and delete all records from the AR System User Central File form. 3. Export and delete all records from the AR System User Preference form. 4. Temporary Disable Automatic Processes (performance tuning to make upgrade complete faster): Escalations Alerts Archive Log Files Server Events 5. Temporary Decrease Threads count (max 2 each) to enable faster re-caching during upgrade. 6. Shut Down AR System. 7. Verify that the Oracle 11g 64 bit client has been installed on the server and update the tnsnames file for this client. 8. Verify that at least java 1.6 32 and 64 bit has been installed. 9. Comment out
Re: Help with upgrade path
Thanks for the info Theo. One more question. Did you migrate the 3rd party pieces to 64bit as well? We are using Exchange/Outlook for our mail server so we are using the MAPI protocol for the email engine. This means we have to use the 32bit JRE. I'm wondering whether I need to use the 32bit 2.4.x Apache HTTPD or whether I can use the 64bit. On Mon, 15 Dec 2014 21:10:37 +0200, Theo Fondse (GMail) theo.fon...@gmail.com wrote: Hi Carina, We upgraded our Custom-Only 7.1/10g/Slolaris server recently to 7.6.4/11g/RedHat. I always suggest NOT to skip a major version when doing an upgrade, due to the fact that BMC only supports the last 3 versions, and therefore, might not test their software during development for upgrades from unsupported versions at the time. (I seriously doubt that BMC would have tested a straight upgrade from 7.1 to 7.6.04 or much less 8.0 or 8.1, due to their version support policies). Before I started my current stint at the company where I am working now, they attempted an upgrade from 7.1 to 7.6.4 and failed several times. Even with the assistance of a local support partner, the upgrade failed and they eventually gave up. The solution to the problem later turned out to be that you should not skip any major versions and go through the installer logs to find out what went wrong if the installer fails. We found a caveat with some of the AR System forms and tables which had to be addressed manually before the upgrade in order to get the upgrade to work. I suggest the following steps which worked for us to do a successful upgrade (please test it first on a development/test environment before doing this on prod): 1. Back up the current DB (full DB export dump). 2. Export and delete all records from the AR System User Central File form. 3. Export and delete all records from the AR System User Preference form. 4. Temporary Disable Automatic Processes (performance tuning to make upgrade complete faster): Escalations Alerts Archive Log Files Server Events 5. Temporary Decrease Threads count (max 2 each) to enable faster re-caching during upgrade. 6. Shut Down AR System. 7. Verify that the Oracle 11g 64 bit client has been installed on the server and update the tnsnames file for this client. 8. Verify that at least java 1.6 32 and 64 bit has been installed. 9. Comment out Db-Character-Set: UTF-8 parameter in ar.conf file if using UTF-8. 10.Run the following script on Oracle (fix for SW00327170): CREATE TABLE SCHEMA_ARCHIVE_BACKUP AS SELECT SCHEMAID, ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE; COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = NULL; COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NUMBER (15)); COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = (SELECT ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE_BACKUP WHERE SCHEMA_ARCHIVE_BACKUP.SCHEMAID = SCHEMA_ARCHIVE.SCHEMAID); COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NOT NULL); 11.Upgrade to ARS 7.5.0 12.Upgrade to ARS 7.6.04 SP5 13.Upgrade to ARS 8.0 14.Upgrade to ARS 8.1 15.Restore original config for Escalations Alerts Archive Log Files Server Events Threads count 16.Import backed up records for the AR System User Central File form. 17.Import backed up records for the AR System User Preference form. HTH, Best Regards, Theo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: 12 December 2014 22:44 To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path My suggestion Take a backup of the Oracle 10g data and copy/restore it to the Oracle 12c (Your DBA could also do this with oracle DataPump). Install 8.1 on the new server against the copy/restored data. When installing it should ask you if you want to upgrade or start new in the database. Choose upgrade. (You do NOT need to have an existing set of ARS binaries on the new server to choose upgrade as this only refers to the database data) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Carina Burns Sent: Friday, December 12, 2014 11:38 AM To: arslist@ARSLIST.ORG mailto:arslist@ARSLIST.ORG Subject: Help with upgrade path Greetings!!! I am turning to you all for suggestions for an upgrade path for our ARS system. I've contacted BMC for advice, however our support contract level is Basic... which is also the adjective I would use to describe my current level of customer satisfaction. Has anyone gone from ARS 7.1 to 8.1? How did you do it? If you don't want to wade thru my specifics,
Re: Help with upgrade path
And I just read your other replyYou likely don't run HTTPD because you don't run Mid-Tier... So I'll open the question to others, will Apache HTTPD 2.4.x 64bit work well with the 32bit JRE? And is anyone running the later versions of JRE? The support matrix lists JRE6u17 but Oracle has that in the Nope column. On Fri, 19 Dec 2014 10:45:22 -0500, Carina Burns carina.bu...@risd.org wrote: Thanks for the info Theo. One more question. Did you migrate the 3rd party pieces to 64bit as well? We are using Exchange/Outlook for our mail server so we are using the MAPI protocol for the email engine. This means we have to use the 32bit JRE. I'm wondering whether I need to use the 32bit 2.4.x Apache HTTPD or whether I can use the 64bit. On Mon, 15 Dec 2014 21:10:37 +0200, Theo Fondse (GMail) theo.fon...@gmail.com wrote: Hi Carina, We upgraded our Custom-Only 7.1/10g/Slolaris server recently to 7.6.4/11g/RedHat. I always suggest NOT to skip a major version when doing an upgrade, due to the fact that BMC only supports the last 3 versions, and therefore, might not test their software during development for upgrades from unsupported versions at the time. (I seriously doubt that BMC would have tested a straight upgrade from 7.1 to 7.6.04 or much less 8.0 or 8.1, due to their version support policies). Before I started my current stint at the company where I am working now, they attempted an upgrade from 7.1 to 7.6.4 and failed several times. Even with the assistance of a local support partner, the upgrade failed and they eventually gave up. The solution to the problem later turned out to be that you should not skip any major versions and go through the installer logs to find out what went wrong if the installer fails. We found a caveat with some of the AR System forms and tables which had to be addressed manually before the upgrade in order to get the upgrade to work. I suggest the following steps which worked for us to do a successful upgrade (please test it first on a development/test environment before doing this on prod): 1.Back up the current DB (full DB export dump). 2.Export and delete all records from the AR System User Central File form. 3.Export and delete all records from the AR System User Preference form. 4.Temporary Disable Automatic Processes (performance tuning to make upgrade complete faster): Escalations Alerts Archive Log Files Server Events 5.Temporary Decrease Threads count (max 2 each) to enable faster re-caching during upgrade. 6.Shut Down AR System. 7.Verify that the Oracle 11g 64 bit client has been installed on the server and update the tnsnames file for this client. 8.Verify that at least java 1.6 32 and 64 bit has been installed. 9.Comment out Db-Character-Set: UTF-8 parameter in ar.conf file if using UTF-8. 10. Run the following script on Oracle (fix for SW00327170): CREATE TABLE SCHEMA_ARCHIVE_BACKUP AS SELECT SCHEMAID, ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE; COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = NULL; COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NUMBER (15)); COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = (SELECT ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE_BACKUP WHERE SCHEMA_ARCHIVE_BACKUP.SCHEMAID = SCHEMA_ARCHIVE.SCHEMAID); COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NOT NULL); 11. Upgrade to ARS 7.5.0 12. Upgrade to ARS 7.6.04 SP5 13. Upgrade to ARS 8.0 14. Upgrade to ARS 8.1 15. Restore original config for Escalations Alerts Archive Log Files Server Events Threads count 16. Import backed up records for the AR System User Central File form. 17. Import backed up records for the AR System User Preference form. HTH, Best Regards, Theo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: 12 December 2014 22:44 To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path My suggestion Take a backup of the Oracle 10g data and copy/restore it to the Oracle 12c (Your DBA could also do this with oracle DataPump). Install 8.1 on the new server against the copy/restored data. When installing it should ask you if you want to upgrade or start new in the database. Choose upgrade. (You do NOT need to have an existing set of ARS binaries on the new server to choose upgrade as this only refers to the database data) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Carina Burns Sent: Friday, December 12, 2014 11:38 AM To: arslist@ARSLIST.ORG mailto:arslist@ARSLIST.ORG Subject: Help with upgrade path
Re: Help with upgrade path
Hi Carina, We moved everything to 64-bit, but also installed a 32-bit copy of Java especially for the Email Engine. Best Regards, Theo On Fri, Dec 19, 2014 at 5:45 PM, Carina Burns carina.bu...@risd.org wrote: Thanks for the info Theo. One more question. Did you migrate the 3rd party pieces to 64bit as well? We are using Exchange/Outlook for our mail server so we are using the MAPI protocol for the email engine. This means we have to use the 32bit JRE. I'm wondering whether I need to use the 32bit 2.4.x Apache HTTPD or whether I can use the 64bit. On Mon, 15 Dec 2014 21:10:37 +0200, Theo Fondse (GMail) theo.fon...@gmail.com wrote: Hi Carina, We upgraded our Custom-Only 7.1/10g/Slolaris server recently to 7.6.4/11g/RedHat. I always suggest NOT to skip a major version when doing an upgrade, due to the fact that BMC only supports the last 3 versions, and therefore, might not test their software during development for upgrades from unsupported versions at the time. (I seriously doubt that BMC would have tested a straight upgrade from 7.1 to 7.6.04 or much less 8.0 or 8.1, due to their version support policies). Before I started my current stint at the company where I am working now, they attempted an upgrade from 7.1 to 7.6.4 and failed several times. Even with the assistance of a local support partner, the upgrade failed and they eventually gave up. The solution to the problem later turned out to be that you should not skip any major versions and go through the installer logs to find out what went wrong if the installer fails. We found a caveat with some of the AR System forms and tables which had to be addressed manually before the upgrade in order to get the upgrade to work. I suggest the following steps which worked for us to do a successful upgrade (please test it first on a development/test environment before doing this on prod): 1. Back up the current DB (full DB export dump). 2. Export and delete all records from the AR System User Central File form. 3. Export and delete all records from the AR System User Preference form. 4. Temporary Disable Automatic Processes (performance tuning to make upgrade complete faster): Escalations Alerts Archive Log Files Server Events 5. Temporary Decrease Threads count (max 2 each) to enable faster re-caching during upgrade. 6. Shut Down AR System. 7. Verify that the Oracle 11g 64 bit client has been installed on the server and update the tnsnames file for this client. 8. Verify that at least java 1.6 32 and 64 bit has been installed. 9. Comment out Db-Character-Set: UTF-8 parameter in ar.conf file if using UTF-8. 10.Run the following script on Oracle (fix for SW00327170): CREATE TABLE SCHEMA_ARCHIVE_BACKUP AS SELECT SCHEMAID, ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE; COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = NULL; COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NUMBER (15)); COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = (SELECT ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE_BACKUP WHERE SCHEMA_ARCHIVE_BACKUP.SCHEMAID = SCHEMA_ARCHIVE.SCHEMAID); COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NOT NULL); 11.Upgrade to ARS 7.5.0 12.Upgrade to ARS 7.6.04 SP5 13.Upgrade to ARS 8.0 14.Upgrade to ARS 8.1 15.Restore original config for Escalations Alerts Archive Log Files Server Events Threads count 16.Import backed up records for the AR System User Central File form. 17.Import backed up records for the AR System User Preference form. HTH, Best Regards, Theo -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: 12 December 2014 22:44 To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path My suggestion Take a backup of the Oracle 10g data and copy/restore it to the Oracle 12c (Your DBA could also do this with oracle DataPump). Install 8.1 on the new server against the copy/restored data. When installing it should ask you if you want to upgrade or start new in the database. Choose upgrade. (You do NOT need to have an existing set of ARS binaries on the new server to choose upgrade as this only refers to the database data) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Carina Burns Sent: Friday, December 12, 2014 11:38 AM To: arslist@ARSLIST.ORG mailto:arslist@ARSLIST.ORG Subject: Help with upgrade path Greetings!!! I am turning to you all for suggestions for an upgrade path for our
AUTO: Luisa Clotilde Carena è assente dall'ufficio. (tornerà il 05/01/2015)
Sono fuori dall'ufficio fino a 05/01/2015 Risponderò al messaggio al mio ritorno. Nota: Questa è una risposta automatizzata al messaggio Re: Help with upgrade path inviata il 19/12/2014 17.02.29. Questa è l'unica notifica che verrà ricevuta mentre la persona è assente. La presente comunicazione e' destinata esclusivamente al soggetto indicato piu' sopra quale destinatario o ad eventuali altri soggetti autorizzati a riceverla. Essa contiene informazioni strettamente confidenziali e riservate, la cui comunicazione o diffusione a terzi e' proibita, salvo che non sia stata espressamente autorizzata.Se avete ricevuto questa comunicazione per errore, Vi preghiamo di darne immediata comunicazione al mittente e di cancellarne ogni evidenza dai Vostri supporti. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
Hi Carina, We are running Mid-Tier, but with Tomcat on it's own and without HTTPD. You do not need httpd to run mid-tier unless you want to host other normal web sites/pages. Mid-Tier is perfectly happy on Tomcat only. (You can even configure Tomcat to bind on Port 80 in stead of 8080 if you want to.) Best Regards, Theo On Fri, Dec 19, 2014 at 5:52 PM, Carina Burns carina.bu...@risd.org wrote: And I just read your other replyYou likely don't run HTTPD because you don't run Mid-Tier... So I'll open the question to others, will Apache HTTPD 2.4.x 64bit work well with the 32bit JRE? And is anyone running the later versions of JRE? The support matrix lists JRE6u17 but Oracle has that in the Nope column. On Fri, 19 Dec 2014 10:45:22 -0500, Carina Burns carina.bu...@risd.org wrote: Thanks for the info Theo. One more question. Did you migrate the 3rd party pieces to 64bit as well? We are using Exchange/Outlook for our mail server so we are using the MAPI protocol for the email engine. This means we have to use the 32bit JRE. I'm wondering whether I need to use the 32bit 2.4.x Apache HTTPD or whether I can use the 64bit. On Mon, 15 Dec 2014 21:10:37 +0200, Theo Fondse (GMail) theo.fon...@gmail.com wrote: Hi Carina, We upgraded our Custom-Only 7.1/10g/Slolaris server recently to 7.6.4/11g/RedHat. I always suggest NOT to skip a major version when doing an upgrade, due to the fact that BMC only supports the last 3 versions, and therefore, might not test their software during development for upgrades from unsupported versions at the time. (I seriously doubt that BMC would have tested a straight upgrade from 7.1 to 7.6.04 or much less 8.0 or 8.1, due to their version support policies). Before I started my current stint at the company where I am working now, they attempted an upgrade from 7.1 to 7.6.4 and failed several times. Even with the assistance of a local support partner, the upgrade failed and they eventually gave up. The solution to the problem later turned out to be that you should not skip any major versions and go through the installer logs to find out what went wrong if the installer fails. We found a caveat with some of the AR System forms and tables which had to be addressed manually before the upgrade in order to get the upgrade to work. I suggest the following steps which worked for us to do a successful upgrade (please test it first on a development/test environment before doing this on prod): 1.Back up the current DB (full DB export dump). 2.Export and delete all records from the AR System User Central File form. 3.Export and delete all records from the AR System User Preference form. 4.Temporary Disable Automatic Processes (performance tuning to make upgrade complete faster): Escalations Alerts Archive Log Files Server Events 5.Temporary Decrease Threads count (max 2 each) to enable faster re-caching during upgrade. 6.Shut Down AR System. 7.Verify that the Oracle 11g 64 bit client has been installed on the server and update the tnsnames file for this client. 8.Verify that at least java 1.6 32 and 64 bit has been installed. 9.Comment out Db-Character-Set: UTF-8 parameter in ar.conf file if using UTF-8. 10. Run the following script on Oracle (fix for SW00327170): CREATE TABLE SCHEMA_ARCHIVE_BACKUP AS SELECT SCHEMAID, ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE; COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = NULL; COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NUMBER (15)); COMMIT; UPDATE SCHEMA_ARCHIVE SET ARCHIVEFROMFORM = (SELECT ARCHIVEFROMFORM FROM SCHEMA_ARCHIVE_BACKUP WHERE SCHEMA_ARCHIVE_BACKUP.SCHEMAID = SCHEMA_ARCHIVE.SCHEMAID); COMMIT; ALTER TABLE SCHEMA_ARCHIVE MODIFY (ARCHIVEFROMFORM NOT NULL); 11. Upgrade to ARS 7.5.0 12. Upgrade to ARS 7.6.04 SP5 13. Upgrade to ARS 8.0 14. Upgrade to ARS 8.1 15. Restore original config for Escalations Alerts Archive Log Files Server Events Threads count 16. Import backed up records for the AR System User Central File form. 17. Import backed up records for the AR System User Preference form. HTH, Best Regards, Theo -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: 12 December 2014 22:44 To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path My suggestion Take a backup of the Oracle 10g data and copy/restore it to the Oracle 12c (Your DBA could also do this with oracle DataPump). Install 8.1 on the new server against the copy/restored data. When installing it should ask you if you
Re: Help with upgrade path
I just searched oracle support and can't find anything on SW00327170. The only thing listed is a bug that isn't a bug but a config issue with OraDB 7.2. Do you have any other reference number or doc id for this archive fix? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
I just looked and that column in our linux Ora10g Schema_archive table is a varchar2(254) with no “not null” constraint. I don’t think I’m going to change it to a number(15) not null column before I try the upgrade since this may be a Solaris only issue. If the upgrade bombs then I’ll look over the install log and see if it’s something I should address. Thanks for the heads up though. From: Theo Fondse [mailto:theo.fon...@gmail.com] Sent: Friday, December 19, 2014 10:25 AM To: Burns, Carina Subject: Re: Help with upgrade path Nope, SW00327170 is on BMC. I see how you could have thought it was on Oracle... :-) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
You're welcome! Let me know if the upgrade works for you without running the SW00327170 script. Would be interesting to note. Good luck with the rest of your upgrade hope all goes well! On Fri, Dec 19, 2014 at 7:10 PM, Carina Burns carina.bu...@risd.org wrote: I just looked and that column in our linux Ora10g Schema_archive table is a varchar2(254) with no “not null” constraint. I don’t think I’m going to change it to a number(15) not null column before I try the upgrade since this may be a Solaris only issue. If the upgrade bombs then I’ll look over the install log and see if it’s something I should address. Thanks for the heads up though. From: Theo Fondse [mailto:theo.fon...@gmail.com] Sent: Friday, December 19, 2014 10:25 AM To: Burns, Carina Subject: Re: Help with upgrade path Nope, SW00327170 is on BMC. I see how you could have thought it was on Oracle... :-) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
Interesting! I put the question in on my support ticket as this doc on software requirements suggests HTTPD is required to install ARS 8.1 https://docs.bmc.com/docs/display/public/ars81/Software+requirements And... it drives me nuts that the minimums are specified on the compatibility matrix but not which most recent version is stable. You said you installed both the 32bit and 64bit JRE's? Which versions did you use? On Fri, 19 Dec 2014 18:09:06 +0200, Theo Fondse theo.fon...@gmail.com wrote: Hi Carina, We are running Mid-Tier, but with Tomcat on it's own and without HTTPD. You do not need httpd to run mid-tier unless you want to host other normal web sites/pages. Mid-Tier is perfectly happy on Tomcat only. (You can even configure Tomcat to bind on Port 80 in stead of 8080 if you want to.) Best Regards, Theo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with upgrade path
Do you have any data in the ARCHIVEFROMFORM column? If not then you should be safe. Since we did not use archiving all we had to do was make sure it was empty We are on Linux as well and there was a few small issues going from 6.3 to 7.6.04 Here is the script we used to correct them truncate table ALERT_USER; commit; -- Since no one can be logged in to the Alert tool while the upgrade is going on it seemed a good time to clear the list -- Backup FIELD_ENUM Create Table FWG_FIELD_ENUM as select * from FIELD_ENUM; commit; Update FIELD_ENUM set ENUMSTYLE = NULL; COMMIT; ALTER TABLE FIELD_ENUM MODIFY (ENUMSTYLE NUMBER(15)); COMMIT; Update Field_ENUM f Set ENUMSTYLE = ( Select ENUMSTYLE from FWG_FIELD_ENUM Where SCHEMAID=f.SCHEMAID and FIELDID=f.FIELDID) Where exists (Select ENUMSTYLE from FWG_FIELD_ENUM Where SCHEMAID=f.SCHEMAID and FIELDID=f.FIELDID); Commit; -- Backup FILTER_NOTIFY Create Table FWG_FILTER_NOTIFY as select * from FILTER_NOTIFY; Commit; Update FILTER_NOTIFY set BEHAVIOR = NULL, PERMISSION=NULL; Commit; ALTER TABLE FILTER_NOTIFY MODIFY (BEHAVIOR NUMBER(15), PERMISSION NUMBER(15) ); COMMIT; Update FILTER_NOTIFY set BEHAVIOR = 0, PERMISSION=0; Commit; -- Backup SCHEMA_ARCHIVE Create Table FWG_SCHEMA_ARCHIVE as select * from SCHEMA_ARCHIVE; Commit; Update SCHEMA_ARCHIVE set ARCHIVEFROMFORM=NULL; Commit; In order to speed up the upgrade I truncated the Flashboards historical server statistics data -- Flashboards 209 = FB_CUMULATIVESERVERSTATISTICS, 210 = FB_NONCUMULATIVESERVERSTATISTI Truncate Table T209 Drop Storage; Truncate Table H209 Drop Storage; Truncate Table B209 Drop Storage; Truncate Table T210 Drop Storage; Truncate Table H210 Drop Storage; Truncate Table B210 Drop Storage; These forms were converted to Vendor Forms (We didn't use Flashboards so I could just drop them and the upgrade created the new Vendor ones) FB:Alarm Monitor FB:DataSourceVariables FB:Flashboards FB:Variable FB:Variable Attributes Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Carina Burns Sent: Friday, December 19, 2014 11:11 AM To: arslist@ARSLIST.ORG Subject: Re: Help with upgrade path I just looked and that column in our linux Ora10g Schema_archive table is a varchar2(254) with no “not null” constraint. I don’t think I’m going to change it to a number(15) not null column before I try the upgrade since this may be a Solaris only issue. If the upgrade bombs then I’ll look over the install log and see if it’s something I should address. Thanks for the heads up though. -Original Message- From: Theo Fondse [mailto:theo.fon...@gmail.com] Sent: Friday, December 19, 2014 10:25 AM To: Burns, Carina Subject: Re: Help with upgrade path Nope, SW00327170 is on BMC. I see how you could have thought it was on Oracle... :-) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
