CA Service Management

Hello,

I have been using Service Desk for over six years, the last three using Oracle as the backend database. I have found along the way a few challenges on how servicedesk patches are maintained by CA support for the oracle platform. I will be happy to share my experiences and how we have overcome these challenges. So if you out there are using Servicedesk with oracle, I encourage you to respond to this post.

I have the impression that we are a very small percentaje among all the sql server implementations, and I am sure that it will be very beneficial to all of us to share these experiences.

I look forward to hear from you soon.

thanks

Efra

epruneda wrote:

I have been using Service Desk for over six years, the last three using Oracle as the backend database. I have found along the way a few challenges on how servicedesk patches are maintained by CA support for the oracle platform. I will be happy to share my experiences and how we have overcome these challenges. So if you out there are using Servicedesk with oracle, I encourage you to respond to this post.

I have the impression that we are a very small percentaje among all the sql server implementations, and I am sure that it will be very beneficial to all of us to share these experiences.

Hello Efra,

Oracle is a great topic for discussion. I'm sure that anything that you post here on Oracle will be gratefully received.

You're right that Oracle is the lesser used of databases compared to SQL now. I really noticed that swing in database choice over ten years ago. Oracle and Ingress databases formed a significant part of the install base, along with Solaris/UNIX servers. Today the majority by far is Windows/SQL.

That being said, globally there are still quite a number of Oracle sites, and some of the biggest sites are Oracle shops.

My perception of Oracle issues relates to the volume of "eyes on screens." It seems that SQL specific issues are detected sooner, simply because of the greater number of sites.

I'll recommend this thread to a few of our local sites. In the meantime, feel free to add any tips or comments.

Thanks, Kyle_R.

The following are our experiences upgrading from Servicedesk 12.5 to 12.7, I am sharing these with the hope that those few oracle users respond and maybe some time soon we could form a oracle-back-end Servicedesk user group that could help CA to support this great product a little better with a non-sql platform.

We had a number of Oracle related issues during the upgrade process. Here is the first one:

1. Issue with document TEC578669

We decided to follow CA's advice and use the "Swing box" approach to upgrade/migrate to the new version. This approach basically needs two new environments to be built from scratch: a swing and a new prod env. The whole idea is not to run the upgrade on the current production but to copy the database to an intermediary environment (Swing) and massage the data there to make it a 12.7 env, and then separately create a brand new 12.7 env (New prod) that has never been anything other than a 12.7. The last step is to replace the 'empty' 12.7 database in New prod with the upgraded database from Swing. This approach has the benefit that your current prod is never touched so if anything goes wrong on upgrade weekend (knock on wood!), all you need to do is bring the old env back online. The other big benefit is that the New prod env does not has any remnants of the former version, all those marked incompatible files (called legacy files by CA) are not there. This should make a much better and cleaner environment moving forward.

The document I am referring to, has detailed steps on all the tasks that need to be done in order to achieve the upgrade method described above. First of all, steps 4 and 5 are SQL server specific, it would be nice to add a note to Oracle users stating that you need to use oracle-specific utilities to achieve the same results.

The problem that we had was that once we completed Part 2 to prepare the Swing env by replicating our current prod in it, we found that all the data in the 40+ custom tables that we have added over the years to the MDB database was gone. Going back to analyze what happened, I found that step 12 asked to do a pdm_publish in order to add all these customizations to the newly installed current prod version (in our case 12.5), but this caused that all those tables to be completely wiped out. I am guessing that this doesn’t happen when you have a sql server database. So the revised procedure for us Oracle users, would be to copy the contents of the two wsp tables (wsptbl and wspcol) BEFORE the current prod database is copied over, and then do the pdm_publish. In this way all those new tables and columns would have been created in the vanilla database and by the time the current prod mdb is copied over, the Swing env app would already ‘know’ about customizations and those tables would not have been wiped out.

So have any other Oracle-based users have used the Swing method? Did you have the same issue? How about SQL users, I am guessing that this was not an issue for you guys?

I look forward to hear your feedback, thank you.

We had two more important issues with our upgrade; I will post those later this week, so stay tuned. :smile

Efra

epruneda wrote:

The following are our experiences upgrading from Servicedesk 12.5 to 12.7, I am sharing these with the hope that those few oracle users respond and maybe some time soon we could form a oracle-back-end Servicedesk user group that could help CA to support this great product a little better with a non-sql platform.

We had a number of Oracle related issues during the upgrade process. Here is the first one:

1. Issue with document TEC578669

We decided to follow CA's advice and use the "Swing box" approach to upgrade/migrate to the new version. This approach basically needs two new environments to be built from scratch: a swing and a new prod env. The whole idea is not to run the upgrade on the current production but to copy the database to an intermediary environment (Swing) and massage the data there to make it a 12.7 env, and then separately create a brand new 12.7 env (New prod) that has never been anything other than a 12.7. The last step is to replace the 'empty' 12.7 database in New prod with the upgraded database from Swing. This approach has the benefit that your current prod is never touched so if anything goes wrong on upgrade weekend (knock on wood!), all you need to do is bring the old env back online. The other big benefit is that the New prod env does not has any remnants of the former version, all those marked incompatible files (called legacy files by CA) are not there. This should make a much better and cleaner environment moving forward.

The document I am referring to, has detailed steps on all the tasks that need to be done in order to achieve the upgrade method described above. First of all, steps 4 and 5 are SQL server specific, it would be nice to add a note to Oracle users stating that you need to use oracle-specific utilities to achieve the same results.

The problem that we had was that once we completed Part 2 to prepare the Swing env by replicating our current prod in it, we found that all the data in the 40+ custom tables that we have added over the years to the MDB database was gone. Going back to analyze what happened, I found that step 12 asked to do a pdm_publish in order to add all these customizations to the newly installed current prod version (in our case 12.5), but this caused that all those tables to be completely wiped out. I am guessing that this doesn’t happen when you have a sql server database. So the revised procedure for us Oracle users, would be to copy the contents of the two wsp tables (wsptbl and wspcol) BEFORE the current prod database is copied over, and then do the pdm_publish. In this way all those new tables and columns would have been created in the vanilla database and by the time the current prod mdb is copied over, the Swing env app would already ‘know’ about customizations and those tables would not have been wiped out.

So have any other Oracle-based users have used the Swing method? Did you have the same issue? How about SQL users, I am guessing that this was not an issue for you guys?

I look forward to hear your feedback, thank you.

We had two more important issues with our upgrade; I will post those later this week, so stay tuned. :smile

Efra

Hello Efra,
[color=#1a770c]
Thank you very much for taking the time to detail your Oracle experiences[color]. This will be appreciated by our Oracle clients - and others!

There are more Oracle sites out there, I know it. So I suggest you keep posting to new threads and maybe you'll draw them out of the woodwork. If you bump into any at a CA event, encourage them to post here. :smile

I won't update the Swing Box document, but I'll put a link from that thread to this one, and maybe someone will be good enough to update it later.

And to those Oracle sites out there, please post! Questions about Oracle experiences best come from the customer base.

Thanks! Kyle_R.

Hello!

We use Oracle+RHEL.
English is not my native language. Your word for this is "challenge"? :-)

Thank you for your quick reply Audrey!

Yes sometimes I would call using oracle a challenge, you can see that by the fact most of Servicedesk's support documents (if not all) have all the steps asuming that you have SQL server. Oh well!

May I ask which Servicedesk version are you using? We are in about to move from 12.5 to 12.7 and are also moving from oracle 10 to oracle 11.

Please see my next post on the challenges that we faced when we upgrade using the "swing box" method recommended by CA.

Cheers!

Efra