We are having problems with database performance at some of our bigger
customers. Our biggest customer has a 1.1 TB database and they are not
happy.

We have done a number of tests on the system and every indication is that we
have a disk problem. The CPU never exceeds 25% utilization but the drives
are high 90% all the time. Our current model is a standard install on a big
SAN disk.

A solution is being presented that would take our most active table and
split it up into smaller units on separate servers. We would then have a
master table in the production database that would tell the application
where the records for a customer had been re-routed. (Customer X has his
records in server ABC, database 123, Table XYZ ... Customer Y has his on
server QQQ database 555 Table PQR)

What are your thoughts and do you have a better idea?

Thanks!
Richard

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote

Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load? I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load? Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers. It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Richard Douglass" <RDouglass (AT) arisinc (DOT) com> wrote