Re: Test of 8.1.7.4->10gr2 upgrade, platform important?

Yes, you're right. (I guess.) "Knowing" these things is just common sense -- at least for an IT professional with any amount of experience. I've been assuming that your "challenge" is in explaining this stuff to IT management, but that's hardly a safe assumption...

Explaining this stuff to IT management *should* be unnecessary, and I'm quite serious in saying that if I needed to explain such stuff frequently, I would start looking for new managers to report to.

Explaining this stuff to non-IT managers *could* be challenging, but should not be impossible. Personally, I'd start with each of those things I said should be the "same", and place them on a list. Then go through them one at a time, and explain how even minor differences in each category can completely invalidate any testing you have done, or make certain types of tests impossible. Be prepared to lose on a few points. If you're talking to the CFO, for example, he/she may not *care* that you can't do meaningful load/performance tests with half as many CPUs as you have in production, but then he/she is also in a position to (legitimately) make a business decision to forgo that particular type of testing. After all, what you test and how you test it is just as much (or more) as "business" decision as a "technical" decision. At least until the business decisions start to prevent the technical people from doing their jobs.

(I recall many years ago discussing with a CFO the need to have a UPS installed for his new SAP environment. It took some time, but I think I eventually convinced him it was as necessary as fire insurance. In fact, that may have been the analogy that clinched it...)

Anyway, good luck with this. It sounds like you know what you need -- I hope you're able to get it.

Bjørn Dörr Jensen wrote:

> Hi!
> thank you for the examples, i fully agree.
> Every difference is an candidate for wasting time!
> One thing is to know the right thing another to explain it
> understandable for management ;-)
> /Bjoern
>
> ----- Original Message -----
> *From:* Mark Brinsmead <mailto:mark.brinsmead_at_shaw.ca>
> *To:* B.D.Jensen_at_gmx.net <mailto:B.D.Jensen_at_gmx.net>
> *Cc:* Hemant K Chitale <mailto:hkchital_at_singnet.com.sg> ;
> oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> *Sent:* Monday, January 16, 2006 8:27 AM
> *Subject:* Re: Test of 8.1.7.4->10gr2 upgrade, platform important?
>
> Bjoern,
>
> This should be simple.
>
> The whole idea to "testing" is to ensure that the thing you are
> testing will actually work when you do it for real. Would you
> test an Oracle 9i -> Oracle 10g upgrade by migrating a database
> from SQL-Server 2000 to Sql-Server 2005? Of course not!
>
> Sure, Oracle is "platform agnostic". If we're not talking
> about religion, the definition of "Agnostic" (from
> 'dictionary.com') is:
>
> *One who is doubtful or noncommittal about something.*
>
> Hmmm... "noncommittal". No wait -- I don't want open a whole
> new discussion here. To be honest, though, in the case of Oracle
> (or the Oracle DBA), the term "platform agnostic" might be better
> defined as:
>
> *One who has no idea how or when a particular platform is
> going to make their life hell.*
>
> It is hardly unheard of for a task or procedure (or query, or
> ....) to work flawlessly on most platforms, and yet blow sky-high
> (usually due to platform-specific bugs) on one or two. Performing
> a migration test for Oracle 9i to 10g on Windows would in no way
> satisfy me that my (proposed) upgrade procedure will actually
> succeed on HP-UX.
>
> Not only should your test environment be on the same platform
> as production, but it (or at least *one* of your test
> environments) should be as close a possible to *physically*
> identical to production. Providing that it is not absolutely
> cost-prohibitive, anyway. ('Course, I personally would argue that
> if you can't afford the *test* environment, you certainly can't
> afford the *production* environment either.) Same model. Same
> OS. Same patches. Same type and number of CPUs. Same amount of
> RAM. Same type and number of I/O controllers. Same type of
> storage. Same firmware. Same... well, I think you get the
> picture. I have seen people get burned by variances in all of
> these...
>
> Anyway, this is not something you should need to explain to
> your management. If "your management" doesn't "get it", then
> maybe you should think about "getting" new management. ;-)
>
> To be fair, though, I *have* had clients or managers balk at
> this myself. Usually, minimal "explanation" is necessary. For
> example, a question like:
>
> If you use Fibre-Channel SAN storage in production, and
> direct-attached SCSI in the test environment, how do you
> proposed to "test" upgrades to the software that manages the
> multi-path I/O in your SAN?
>
> is often all the explanation I've needed. On occasion, I've had
> to point out the (happily rare) need to test devices drivers,
> kernel patches, etc. If that fails, I can tell stories of the
> RDBMS (happily not Oracle) where backups worked fine on
> single-processor servers, but failed (silently!) on
> multi-processor servers. After enough of examples like this, even
> a "manager" will usually "get it". :-)
>
> Cheers,
> -- Mark Brinsmead
> P.S. Apologies to those who read this in text format and find the
> formatting messed up. That is, even more so than the HTML
> version. Sorry -- I succumbed to weakness, and don't have time
> tonight to redo this properly.
>
>
>
> Bjørn Dörr Jensen wrote:
>
>> Hi Hemant!
>> Thank you for your answer! I expected an answer like this, but
>> I'm not
>> having experience wiht upgrade-tasks
>> and without it, it's difficult to convince management about the
>> point of
>> having the right platform for testing...
>> If you or someone else reading this can give me more links about
>> it I'll be
>> happy ;-)
>> Thank all of you for your help!
>> Greetings
>> Bjoern
>>
>> ----- Original Message ----- From: "Hemant K Chitale"
>> <hkchital_at_singnet.com.sg>
>> To: <B.D.Jensen_at_gmx.net>; <oracle-l_at_freelists.org>
>> Sent: Sunday, January 15, 2006 1:24 AM
>> Subject: Re: Test of 8.1.7.4->10gr2 upgrade, platform important?
>>
>>
>>
>> As a rule, the development/test environment is generally the same
>> platform
>> as prod.
>> Of course, Oracle is "platform agnostic" -- you can develop your
>> scheme,
>> stored procedures etc
>> on a database on windows and port them to a database on AIX.
>> But when it comes to upgrading your database, your test upgrades
>> should be
>> on
>> the same platform as prod. Not only will it help you identify
>> platform-specific
>> issues {different OS patches are pre-reqs for 9i/10g}, it will
>> also help you
>> run the actual Oracle installation specific to that platform.
>>
>> You would be running the test upgrade to a different platform
>> from prod only
>> if
>> the test platform is your target platform for the live upgrade --
>> ie you
>> ARE planning
>> a platform migration.
>> Hemant
>> At 03:29 AM Saturday, Bjørn Dörr Jensen wrote:
>>
>>> I suppose that it's very important to test an upgrade in an
>>> environment
>>> similar to production.
>>> Lets say production environment is AIX, database-size about 100Gb.
>>> Can I (=is it meaningfull) to test upgrade in
>>> windows-environment when
>>> production is AIX?
>>
>>
>>
>> Hemant K Chitale
>> http://web.singnet.com.sg/~hkchital
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
>

--
http://www.freelists.org/webpage/oracle-l