Migrate to Oracle 11g

[Former Member]

Dear All,

Presently we are have a Oracle 10.2.0.2 on HP-UX 11.31 IA64. We got the Oracle 10g with SAP Sofrware.

Is it advisable to migrate to 11g in next six months?

Thanks in advance,

Nirav

[Former Member]

Is it advisable to migrate to 11g in next six months? 

My two cents: Absolutely, there is no reason not to do it

Let me link another related thread here:

Cheers Michael

And, yes oltp compression rocks, and i don't expect io problems to increase

[Former Member]

.

[former_member184473]

Hello Nirav,

Just to complement Volker's reply, Oracle 11g on HP-UX IA 64 is support since last March. You can find further information on note [1398634|https://service.sap.com/sap/support/notes/1398634].

For further information about the Installation/Migration you should refer to the installation guide:

-> [Instguide|http://service.sap.com/instguides]

-> Database Upgrades

-> Oracle

-> Upgrade to Oracle Database 11g Release 2 (11.2): UNIX

Note [1431797|https://service.sap.com/sap/support/notes/1431797] you can find problems already known.

Regards,

Eduardo Rezende

[Former Member]

Thanks for your reply.

I forgot to mention in my 1st post that we are using ECC 6.

So according to note 1339724, Oracle 10.2 supported upto 31st July, 2011.

After that SAP may charge addional for Oracle Support which SAP announce in Q1/2011. That may be for next 3 years.

So before 31st July, 2011 is it advisable to upgrade to 11g?

Thanks,

Nirav

[volker_borowski2]

>

> So before 31st July, 2011 is it advisable to upgrade to 11g?
> Nirav

Yes

but as to the restrictions mentioned above may be not NOW but may be in Q1/2011.

If you can save some TB using new compression, cards would be shuffeld again.

Volker

[Former Member]

Thanks for your reply volker.

I can't understand "If you can save some TB using new compression, cards would be shuffeld again."

Thanks,

Nirav

[volker_borowski2]

Hello,

I mean, if you have a DB of some terrabytes, there are studies,

that you can save a remarkable amount of diskspace when you

activate the new compression features of 11g.

To reduce the space of your systems can lower the operational

cost of your systems. So this may be a good reason to do the upgrade

and organize your projects so that you do not require a systemcopy before Q4,

or if you have to do one, do it in a not officially supported way.

If you just have a 100-300GB database I think the money you can save

is not worth the situation to be on unsupported ground.

On the other hand if you can save 5TB from your daily backup and cut down

your deasaster recovery time by some hours because your DB is smaller,

that might be reasons to go for it and work around these restrictions.

Doing it on a sandbox in advance to get operational practice for 11g

would be a reason as well (for the sandbox, not for production).

It depends on what is more important to you. I just want to say, that I'd

not recommend to upgrade just because you can do it now. You just have

to consider the restrictions currently still in place and what they mean to

your specific situation.

Hope this clearifys.

Volker

[Former Member]

Hello Volker,

I have just compressed a freshly reorganized 5 TB Oracle 11g database and it was

2 TB afterwards (the size before a full reorganisation was even 6 TB). This was done

to save disk space. However I don't agree at all. Todays databases are strongly limited

on IO bandwidth, and if we compress Oracle (or DB2 or whatever) databases, this only

aggravates the situation. Lots of SAP dialog users simply cause lots of small random reads

over the database. Now if we reduce storage to reduce costs, then we have less spindles

to serve the database requests. Dialog user response times will suffer.

Oh the other side, batchjobs with full table scans will definitely gain by compression.

For backups I also see no benefit if you have a compressed database. The

LTO drives perform data compression on the fly for free. So it is no big deal

if your database size shrinks, the space on tape will not be reduced significantly.

Maybe the backup duration is shortened a little, but the better your SAN is the

smaller effects you'll see.

Regards,

Mark

[nikolay_kumanov]

Please correct me if I am wrong, but I think 10.2.0.2 is not fully supported anymore. 10.2.0.4 will be fully supported only until end of Q1 2011, afterwards only 10.2.0.5 will be supported and support is free only until 01.08.2011. So in any case you have to do some major or minor upgrade soon to stay fully supported.

I maintain several SAP landscapes for several companies. Considering the year-end and year closing activities, for most of the landscapes we decided to upgrade production systems in September-October 2010, sandbox systems are upgraded, development - very soon to use the summer for testing. One landscape is related to important other projects in Q3 and Q4, so I took the risk and upgraded it early. Upgrade was very smooth, systems are stable, compression produced ~60% space savings, performance for sure is not worse, probably better.

Considerations about installations/system copies are perfectly valid. IMHO, refreshing an already installed QA system should not pose any significant problem. New installations will be another story.

[Former Member]

Hi Mark,

We are also planning to upgrade our systems to 11g and turn on compression.

After compression, do you see any performance or issues other than increased dialog

Response time. It seems compression will reduce the DB size between 60 u2013 70% , which is

A good news.

Other question I have is about backup , Do you think RMAN with compression will save

Backup time & tape significantly ? It would be great if you can share your experience

Thanks

Prince Jose

[volker_borowski2]

Hi Mark,

this might get off-topic to the inital question.

It was not 11g yes/no and what features to use.

It was: 11g: when? and "why when"?

I only wanted to say, that there CAN be reasons, and this one MIGHT be one

worth to be considered when you need to decide pro/con 11g right now or later.

However, the compression feature is one which is quite frequently disscussed right now

and as as you already are at the real frontside it is very interesting to get additional real

life information about that topic.

> ... However I don't agree at all. Todays databases are strongly limited

> on IO bandwidth, and if we compress Oracle (or DB2 or whatever) databases, this only

> aggravates the situation. Lots of SAP dialog users simply cause lots of small random reads

> over the database. Now if we reduce storage to reduce costs, then we have less spindles

> to serve the database requests. Dialog user response times will suffer.

Yeah, could be either way, but the test-scenarios around are currently more talking

about the benefit that compressed data is even more data inside the same amount of cache RAM,

so that in fact you will do less IO in average.

Do you say so from messured data from your system, from subjective click-and-feel,

from user-feedback or just some belly-feelings

(which must not be bad, I tend to listen to my belly very carefully )?

I have no data about this at all so I am very curious.

> For backups I also see no benefit if you have a compressed database. The

> LTO drives perform data compression on the fly for free. So it is no big deal

> if your database size shrinks, the space on tape will not be reduced significantly.

That is a point, I disagree with. For backup it might not be relevant if a tape is

doing compression (allthough it can only be a streaming type like Huffman or

repeated value elimination, or something like that), but for restore it very well makes a

difference if you need to write 2 TB or 6 TB back to your disks.

(even if they are on less spindels)

Curious about your thoughts about this.

Best regards

Volker

[Former Member]

Hi Mark,

they call the feature OLTP Compression now - wich means it's use is also meant for high transaction systems.

Consider a more efficient use of the DB Buffer (table/index blocks) by reducing physical reads to the disks.

So a good guess would be that the feature let have you the cake (storage savings) and you can eat it, too.

We dealing mostly with high storage costs and did the compression since 10g (SAP BW).

Now we expecting the ERP would also benefit from it.

bye

yk

[volker_borowski2]

Hi,

unless you have needs for specific functionality (i.e. compression),

I would avoid 11g as long as no plain installation / systemcopy for

your release is available (mind to remember it is annonced for Q4).

10.2.0.4 is rock solid and I would not like to fool around with systemcopy

on not yet supported ground. If you are on old releases (4.6 / 4.7) and

consider to upgrade to ECC 5.0 (for whatever reason) I would avoid as well,

as it is currently not supported to upgrade to ECC 5.0 with a 11g DB.

Volker