Moving from Oracle do SQL Server

[Former Member]

In my SAP instalation we are thinking to move from SAP/Oracle to SAP/SQL Server.

What do you think about this ?

The reason for this move is we have more knowledge in SQL Server Than Oracle.

[Former Member]

Hi,

you have to consider also the workload that you will have in the SAP system.

As Lars stated: with ORACLE you are OS-system independent (quite) and you invest into the future with getting to know ORACLE.

I don't want to step into ORACLE/Microsoft discussions and both databases have their place but in heavy-load environments I would prefer ORACLE.

For a good MS SQL DBA it should take less time to get the knowledge as for a beginner.

[lbreddemann]

>

> As Lars stated: with ORACLE you are OS-system independent (quite) and you invest into the future with getting to know ORACLE.

Just to set that straight. I did not say it like this.

The os-independence you referred to actually applies for all other databases supported by SAP as well (only MS SQL is bound to Windows).

So it would be quite possible to e.g. switch to DB2 or MaxDB to get all the same advantages.

The "invest into the future"-thing.... well, yes it's for sure a good thing to know something about oracle. It's always nice on the CV. But for the company there is no difference concerning 'future stability' wether you go for Oracle, DB2 or MaxDB.

KR Lars

[Former Member]

Ok, sorry.

In theory you're right. All the other DB's have some kind of OS independence.

But independence is maybe not that important - you can run all the DB's on Windows Server if you like...

but here's my opinion:

• Db/2 : you have different database flavours for different OS's

• MAXDB: I wouldn't consider it in high transaction environments

• ORACLE database is the most used for SAP apps - you will find a lot of expert knowledge around (i.e. see threads here in SDN)

Here it's the question what you will gain and what you will loose when you go for another DB.

(1) Do you meet the business growth requirements in the future?

(2) Does the move fit to your SLA (i.e. in terms of workload , transactions per sec. ...) ?

(3) How much administrative overhead you have to consider in your daily database maintenance?

(4) Wich resources you have around that can support you ?

...

It may that you go for MS SQL because only of (4) - it may not because of (1) or (2).

For me (3) is the most important. If I can't get the DB running fast, if I miss my backups and restore procedures I'm out of my job . So I go for less admininstration overhead to have time to support the business

[markus_doehr2]

> * Db/2 : you have different database flavours for different OS's

> * MAXDB: I wouldn't consider it in high transaction environments

> * ORACLE database is the most used for SAP apps - you will find a lot of expert knowledge around (i.e. see threads here in SDN)

Well - this is interesting

Especially the point about MaxDB - what makes you come to the conclusion, that it's not suited for "high transaction environments" (whatever you mean with that)?

Your statement of Oracle is true - however, it's (in my opinion) mainly because many many people have in their mind

Operating system == Windows

Database == Oracle

Especially on the not-so-technically-oriented levels (management) those are often synonyms. There's nothing wrong with that, you just have to argue with $$$ (Oracle is the most expensive database in SAP environments, license and maintenance).

We had not so long ago a likewise discussion after a merger to continue to use our so called "exotic" combination of Linux + MaxDB. In case there was something wrong (with "SAP" in general), people told "Why didn't you choose HP-UX/Oracle, which is known to run very well...", no matter if that problem was related to that combination or not. I think that IF we had chosen that, any problems would have been considered "as is" instead, nobody would have questioned, that the platform/database choice was wrong. So I think that all those discussions are to 90 % a matter of politics and strategy, only 10 % is real technical evaluation and considerations, at least, that's my experience.

Markus

[stefan_koehler]

Hello Markus,

> There's nothing wrong with that, you just have to argue with $$$ (Oracle is the most expensive database in SAP environments, license and maintenance).

> So I think that all those discussions are to 90 % a matter of politics and strategy, only 10 % is real technical evaluation and considerations, at least, that's my experience.

You are absolutely right ...

> Especially the point about MaxDB - what makes you come to the conclusion, that it's not suited for "high transaction environments" (whatever you mean with that)?

I have to say i am the same "old fashion" way.

Our productive logistic system (ERP2005) is round about 3.5 TB and we have a SLA of the average response time with round about 900ms. I personally would never use MaxDB in this environment.

I have to say that i have not much experience with MaxDB, but these few times i had to administrate the MaxDB instances - it was very "strange" to me, if you come out of the oracle world.

The second part - the support: I have opened some MaxDB messages and also of course some Oracle ones.. and my personally impression is that the oracle support is much better. But this maybe different from customer to customer.

Regards

Stefan

[markus_doehr2]

Especially the point about MaxDB - what makes you come to the conclusion, that it's not suited for "high transaction environments" (whatever you mean with that)?

I have to say i am the same "old fashion" way.

Our productive logistic system (ERP2005) is round about 3.5 TB and we have a SLA of the average response time with round about 900ms. I personally would never use MaxDB in this environment.

Our main instance (ERP 2005) is 1.8 TB and we have an avg. repsonse time (ST03N) of 350 - 480 ms, depending on the load of the system. That database is growing about 2 - 4 GB each working day - and it´s running MaxDB

I have to say that i have not much experience with MaxDB, but these few times i had to administrate the MaxDB instances - it was very "strange" to me, if you come out of the oracle world.

I wouldn´t consider it "strange", it´s "install once and forget". If I see how much time I need to set up an Oracle database (install 10.2.0.1, patch 10.2.0.2, apply 40+ single patches where some of the merge patches uninstall already installed patches....) then I´m happy with my MaxDB

The second part - the support: I have opened some MaxDB messages and also of course some Oracle ones.. and my personally impression is that the oracle support is much better. But this maybe different from customer to customer.

I have never had any real issues with the MaxDB support - in contrary but as you said, this is all based on customer experience.

If you have a LiveCache, then you have a MaxDB installation - it´s just a special pecularity but the base is a MaxDB and is handled as such.

Markus

[stefan_koehler]

Hello Markus,

Our main instance (ERP 2005) is 1.8 TB and we have an avg. repsonse time (ST03N) of 350 - 480 ms, depending on the load of the system. That database is growing about 2 - 4 GB each working day - and it´s running MaxDB

hmm that is very interesting... until now i have never met some customer which runs MaxDB in a "big" productive environment.. the ones that i have met used MaxDB only for content/cacheserver or little evaluation systems.. (like we do too)

We are growing round about 25 GB each week and have round about 2.100 concurrent users.... can you please let me know how many concurrent users do you have and in which type of industry are you working (automotive, etc..)?

Regards

Stefan

[markus_doehr2]

Our main instance (ERP 2005) is 1.8 TB and we have an avg. repsonse time (ST03N) of 350 - 480 ms, depending on the load of the system. That database is growing about 2 - 4 GB each working day - and it´s running MaxDB

hmm that is very interesting... until now i have never met some customer which runs MaxDB in a "big" productive environment.. the ones that i have met used MaxDB only for content/cacheserver or little evaluation systems.. (like we do too)

MaxDB has grown up I know a few other MaxDB customers, one has a HUGE retail system (several TBs) running on MaxDB.

We are growing round about 25 GB each week and have round about 2.100 concurrent users.... can you please let me know how many concurrent users do you have and in which type of industry are you working (automotive, etc..)?

ًWe have 800 - 1000 users concurrently online, we´re a metal manufacturing company (get my email in the business card, omit my name and add a "www" in front of the domain). We have no classical industry solution activated but we use almost every "module" including HR in the same system.

I wouldn´t have a problem with adding some application servers and let another some 1000 users work with the system, we would maybe have to add memory to the database server but I´m VERY sure it would work likewise well.

We use AMD Opteron machines from HP (DL585). Imagine, if you would migrate to MaxDB, alone from the savings of the yearly maintenance fee for Oracle you could buy many really BIG (Intel or Opteron) machines

How big is you Oracle SGA? (just curious)

Markus

[stefan_koehler]

Hey,

> How big is you Oracle SGA? (just curious)

We are running our database (on AIX) with 32 GB SGA on a p570 (p5+) and clustered with HACMP.

The application servers are running on 5 JS22 Power6 Blades

Intel and Opteron are not as fast as Power5+ / Power6

And you ... how does your environment look like?

Regards

Stefan

[lbreddemann]

>

> but here's my opinion:
> 
> * MAXDB: I wouldn't consider it in high transaction environments
Of course I've to answer to that ...
The question is: Why wouldn't you?
The SDN portal you're currently using is build on MaxDB.
The SAP Support message system (formerly known as OSS) - a very big system has been moved from Informix to MaxDB and is doing fine.
On comparable hardware MaxDB is really up to Oracle in OLTP.
It may be interesting for you and others to learn more about what customers already did using MaxDB. You can do so here: 
[http://maxdb.sap.com/events/]
There are many presentations of customers available, showing their setup details and the pros/cons they've experienced by using MaxDB.
> Here it's the question what you will gain and what you will loose when you go for another DB.
> (3) How much administrative overhead you have to consider in your daily database maintenance?
> For me  (3) is the most important. If I can't get the DB running fast, if I miss my backups and restore procedures I'm out of my job . So I go for less admininstration overhead to have time to support the business

Well, then you would for sure go for MaxDB as it's by far the one DBMS with the lowest administrative overhead and the lowest call rates within all DBMS supported by SAP.

Although the performance is really good, low administrative needs is where MaxDB really shines.

In fact, MaxDB installations are the only DBMS where I get calls to work on, where the DBAs in charge ask for help, because they've forgotten how to do this or that, just because they never had to do it. This is especially true for Content Server installations. They are mostly treated as install and forget databases and this works pretty nice (try this with Oracle ...).

KR Lars

[markus_doehr2]

Hey,

How big is you Oracle SGA? (just curious)

We are running our database (on AIX) with 32 GB SGA on a p570 (p5+) and clustered with HACMP.

Our production systems DATA_CACHE is 32 GB. We have one four way application server with 48 GB of RAM (where actually ~ 30 GB are used during daytime).

The application servers are running on 5 JS22 Power6 Blades

Intel and Opteron are not as fast as Power5+ / Power6

I´m not sure of that

The ABAP runtime is a single threaded process (a workprocess) and what counts here on the computation side is the raw processor speed (left aside the caches of course).. This is very different for multithreaded applications of course where its superscalar multi-pipe architecture will give a huge benefit

Markus

[lbreddemann]

> I have to say that i have not much experience with MaxDB, but these few times i had to administrate the MaxDB instances - it was very "strange" to me, if you come out of the oracle world.
When I started with MaxDB it was strange to me as well.
When I started with Oracle it was strange to me as well.
But I got to know each of both DBMS. By training, self-education and working with either DBMS.
And now I know both DBMS quite well.
The point is: did you get the same training for MaxDB as for Oracle? 
Did you use the same amount of documentation for MaxDB as for Oracle? 
Just taking over something you know that works on system A A to system B (where A <> B) will most definitively lead to a non-optimal solution for system B. 
> The second part - the support: I have opened some MaxDB messages and also of course some Oracle ones.. and my personally impression is that the oracle support is much better. But this maybe different from customer to customer.
> 
> Regards
> Stefan

Hmm... Sorry I couldn't resist and had a quick look...

With your name and the component BC-DB-SDB or BC-DB-ORA I found 28 customer messages.

Just three of them (10%) had been MaxDB (BC-DB-SDB) messages... looks like there had been more issues with Oracle, doesn't it?

best regards,

Lars

[stefan_koehler]

Hello Lars,

>> Just three of them (10%) had been MaxDB (BC-DB-SDB) messages... looks like there had been more issues with Oracle, doesn't it?

Of course... as i already mentioned... we are using oracle on all our sap ABAP and J2EE installations.

MaxDB is only used in our content and cache server environment.. so i think it is really logical that the most calls are on oracle.

I have also searched for the errors on the net.. but didn't find a solution for MaxDB... in the most oracle error cases i found some explanations / solutions on the net or in metalink....

I think that oracle has the "bigger community" and the chance to find the error faster and maybe by your own is much bigger with oracle....

> In fact, MaxDB installations are the only DBMS where I get calls to work on, where the DBAs in charge ask for help, because they've forgotten how to do this or that, just because they never had to do it

In this point you are absolutely right.. the databases are running without any problem and we forget how to do things in some error cases..

But as i already mentioned.. i am not very into MaxDB.. my opinion is based on experiences and talks with other customers. I was also interested in the experiences of Markus with MaxDB in a bigger SAP environment.. and it seems to work quite well

Regards

Stefan

[Former Member]

Hi all,

If you want to go with MaxDB or MS SQL Server - I will not stop you.

I'm not making money by selling ORACLE database licenses

Consider one thing: Will your business grow?

Will you be fast enough to run daily business with your database in the future ?

I would vote for the technical leader in this area. I really don't want to run a datawarehouse with

10th to hundreds of Terabytes on MaxDB...or a high transaction OLTP system and be paged on my weekend everytime the database went down because of "denial of service"

Good luck

bb

[Former Member]

Hi ,

For our datawarehouse (Oracle 9i RAC ) we wanted to be scalable and fast enough to deliver the business as it is today. So we are not high-transaction but high-longrunning transaction environment.

If we have to grow with the business, we can scale up to their needs - we easily add another "cheap" server with a new instance into the RAC.

We intensivly use logical partitioning on business attributes (time-based) to slice our biggest tables

(about 120 Gbyte pieces , 100-150 Mio. rows).

We have to load a lots of data so we vote for parallel external table loads (nologging, CTAS based) and quickly exchange these with our partitions to be in line with our time window - quite no undo at all.

We have a standby database that is streamed from the RAC instance to move some reporting to another server.

We never thought of another database to use - because there is none that can come up with the features we needed.

Sorry , I will not go to SQL Server or even MAXDB...

[Former Member]

Hi Bernd,

your RAC for SAP experience sounds very good. Would you please share some information about your environment with me: OS, database size etc ..

regards

Barthez

[lbreddemann]

Hi Rui,

although present knowledge is a strong argument consider these points:

- today knowledge about other dbms is relatively cheap to acquire

- the current knowledge will likely be outdated soon and addtional training costs will come up, regardless if you switch the platform or not

- with MS SQL you're moving into a partial lock-in situation as only windows is available as a platform both for the db server and client in SAP environments. Quite often customers have the need of accessing data in a MS SQL database from let say an AIX based SAP installation and need to install an additional application server on windows for this.

- the license fee share for MS SQL installation is not less than for Oracle installations - for MaxDB installations it is.

In any case - a platform switch is always a large project and should only be done if it is really feasible.

Hope that gives something to think about.

KR Lars

[markus_doehr2]

Check

http://service.sap.com/osdbmigration

For production system you will need to (pay) a certified migration consultant.

Apart from that you can use the system copy guide to do the copy (http://service.sap.com/systemcopy).

Migrations of databases and/or operating systems is supported.

Markus