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@xxxxxxx> *To:* B.D.Jensen@xxxxxxx <mailto:B.D.Jensen@xxxxxxx> *Cc:* Hemant K Chitale <mailto:hkchital@xxxxxxxxxxxxxx> ; oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx> *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@xxxxxxxxxxxxxx> To: <B.D.Jensen@xxxxxxx>; <oracle-l@xxxxxxxxxxxxx> 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
-- //www.freelists.org/webpage/oracle-l
