cancel
Showing results for 
Search instead for 
Did you mean: 

MS SQL 2005: Named Instance vs. Default Instance

Former Member
0 Kudos

HI Experts:

I would like to know why does SAP prefer Default Instance over Named Instance.

Our QA server is going to be hosting both TST and LRN instances and we have decided to install both of them with their own MS SQL (Named) instance.

I realize that the resources consumption would increase with two named instances, but it also makes our system more redundant.

Thanks!

Imran

    • Points will be rewarded for good answers **

Accepted Solutions (1)

Accepted Solutions (1)

Matt_Fraser
Active Contributor
0 Kudos

Imran,

A default instance is easier to configure and administer than a named instance, and older releases of R/3 did not deal well with named instances, but current releases have no technical issue with this. Note 98678 describes some of the system settings you may need to consider when setting up a named instance.

Bear in mind that another way to achieve your desired goal of two systems on one server is an MCOD (Multiple Components One Database) installation. With basis 7.00 (and 6.40? not sure) this is actually the default way SAP installs anyway, by putting all the tables into a schema that is named after the SID of the system. In the past, all tables were in the dbo schema, but this is now no longer the case. So, you could have two SAP systems all in the same database, but each with their own schema. I haven't tried this myself, so I'm not sure what pitfalls you might encounter, but it should be possible.

A third way, and probably the easiest way, is to just do one SAP installation, as per normal, but have separate TST and LRN clients in the system. This is much less resource consumption, much less administrative overhead, and all around simpler and less likely to have problems. You just need to ensure that all client-dependent transports (customizing requests) are imported to both clients.

Since these are not production systems (unless you're in the business of providing training), is redundancy so important that you'd add this extra overhead of multiple databases or instances just for that? Also, I'm not sure how much redundancy you're really achieving, since it's still all on the same server. Will you separate the different instances out to their own disk drives, for both database and transaction log?

--Matt

Former Member
0 Kudos

Hi Matt:

Thanks for your prompt reply.

One of the reason we are going with two instances is that in the beginning there will be both training and testing happening at the same time. As always we have very tight timelines and can't afford any significant downtime.

I realize that the OS/Host is a risk factor and if that were to crash we would end up doing a DR anyways. However, with this way we limit any corruption within the DB, it also allows us to indivdually manage the two SQL instances, especially we have to do any bouncing.

As of Basis 700, all issues with Named Instance have been solved. Atleast, we haven't encountered any. We are not using MCOD, but are using multiple DBs on some of the other instances and we found that we were limited in terms of downtime as a lot of coordination was required.

Anyways, thanks for your input!

Cheers

Imran

Former Member
0 Kudos

Hello Imran,

I think for your particular needs, a virtual server per each SID + database would be the way to go. Microsoft Virtual Server environment would be your best (an easiest) bet to carve out two seperate servers hosted by the same physical server.

This will keep the OS and DB maintenance seperate as well....which is one of your main concerns.

I hope this helps, awards points if it does.

Thanks.

Answers (0)