cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
287
Views
0
Helpful
2
Replies
Highlighted
Beginner

Gathering some knowleged

we are considering moving from 5.3 to 6.2 this fall.  I guess as an administrator,  I want to make sure that when 5.3 is shutdown and 6.2 brought up, we don't get any duplicate jobs scheduled, or jobs that may have already run for that day.  I would think we would use the same database, and not create a new copy for the 6.2.

 

What is the best way to handle this?  Never done this before.

 

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Hi there, we have done more than 4 major tidal upgrades at work, the last one, because of the major architectural change, we opted to have consultants on board.  You can definitely do it yourself but you need to allocate a lot of time for planning, upgrade, testing, training etc.  Depending on your size, complexity of jobs and number of users, size of machine there is a huge performance difference between 5.3 and 6.

It is a must to perform this on your test system first and make sure you have Cisco support on hand to guide you along the way if you don't get outside help.

We have had upgrades in the past where we had to roll back (due to something buggy that was not thoroughly tested).  Ideally you will use new servers  and make a copy of your database, point server to copied DB and upgrade the copy.  You also need to make sure you set queue to 0 (maybe even disable all agents) and sanity test a few jobs first prior to totally opening up the queues. 

We normally take a copy of the DB in this state to be sure there is nothing inflight or mid processing.  This way, rolling back is as easy as turning off the new setup and turning old Tidal back on.  How long it takes to copy the original DB needs to be taken into account as well in your timing OR if you decide to upgrade existing DB, the duration for rolling back to backup.

On practices passes, you may want to examine schedules closely and determine what you want to delete or keep - because even if you set queue to 0, if there is something in schedule the events will fire off and you could get a barrage of alerts.  The amount of schedule days you keep affects how long CM upgrade and sync take. I guess pausing scheduler also prevent events from firing - I just don't use that feature as much as setting queue.

There is just so many gotchas, verification/cleanup scripts and tips that an experienced upgrader/consultant can give you to make sure you don't mess up your environment or cause things to take longer to complete.  There are also some server name changes you do behind the scenes when using new servers that only Tidal consultants/tidal support are allowed to provide (since running DB scripts not blessed by Tidal affects support contract)  But at a minimum you always practice on your DEV environment first (ideally not using a copy of PRD DB the first time).  I have also done a practice upgrade pass using copy of PRD DB to get my timing/steps finessed but this is a very delicate thing to do and could cause you a lot of grief (and your job) if you are not sure what you are doing.

Just my two cents.

View solution in original post

2 REPLIES 2
Highlighted

Hi there, we have done more than 4 major tidal upgrades at work, the last one, because of the major architectural change, we opted to have consultants on board.  You can definitely do it yourself but you need to allocate a lot of time for planning, upgrade, testing, training etc.  Depending on your size, complexity of jobs and number of users, size of machine there is a huge performance difference between 5.3 and 6.

It is a must to perform this on your test system first and make sure you have Cisco support on hand to guide you along the way if you don't get outside help.

We have had upgrades in the past where we had to roll back (due to something buggy that was not thoroughly tested).  Ideally you will use new servers  and make a copy of your database, point server to copied DB and upgrade the copy.  You also need to make sure you set queue to 0 (maybe even disable all agents) and sanity test a few jobs first prior to totally opening up the queues. 

We normally take a copy of the DB in this state to be sure there is nothing inflight or mid processing.  This way, rolling back is as easy as turning off the new setup and turning old Tidal back on.  How long it takes to copy the original DB needs to be taken into account as well in your timing OR if you decide to upgrade existing DB, the duration for rolling back to backup.

On practices passes, you may want to examine schedules closely and determine what you want to delete or keep - because even if you set queue to 0, if there is something in schedule the events will fire off and you could get a barrage of alerts.  The amount of schedule days you keep affects how long CM upgrade and sync take. I guess pausing scheduler also prevent events from firing - I just don't use that feature as much as setting queue.

There is just so many gotchas, verification/cleanup scripts and tips that an experienced upgrader/consultant can give you to make sure you don't mess up your environment or cause things to take longer to complete.  There are also some server name changes you do behind the scenes when using new servers that only Tidal consultants/tidal support are allowed to provide (since running DB scripts not blessed by Tidal affects support contract)  But at a minimum you always practice on your DEV environment first (ideally not using a copy of PRD DB the first time).  I have also done a practice upgrade pass using copy of PRD DB to get my timing/steps finessed but this is a very delicate thing to do and could cause you a lot of grief (and your job) if you are not sure what you are doing.

Just my two cents.

View solution in original post

Highlighted

Wow, thanks for the information,  all of it is extremely helpful.  I will pass this along to my management. My bet is we will definelty use professional services for the upgrade, since we don't really have a technical person to handles this regularly.  I appreciate your response.

This widget could not be displayed.