473,889 Members | 1,692 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Database size question

Our database size is currently 4G and is incrementing at a rate of
45M/day. What is the max size of a SQL database? And what is the
size beyond which the server performance will start to go down?

Jul 20 '05
19 21240
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
dchow <dc***@hotmail. com> wrote in message news:<in******* *************** **********@4ax. com>...
SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
disk. Didn't have the server and CPU model with me.
On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
<da******@x.was hington.edu> wrote:
>dchow wrote:
>
>>Our database size is currently 4G and is incrementing at a rate of
>>45M/day. What is the max size of a SQL database? And what is the
>>size beyond which the server performance will start to go down?
>>


<snip>

Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
that most people will ever need to consider. In practice the
limitations are storage capacity and your ability to manage and
backup/restore the database. A 4GB database is not large, and 45MB per
day is a growth of about 16GB per year - 20GB is not particularly
large either.

It's not possible to say when performance will go down - it depends on
the load you place on the server. You can use Performance Monitor and
other tools to monitor CPU, disk access, memory use etc. to see if
there's a bottleneck somewhere. Having a single 50GB hard drive seems
rather limiting, if that's what you have - disk space is cheap, so
most people can afford to get extra disks and use RAID (or perhaps a
SAN/NAS) to improve performance by spreading the databases across
multiple disks.

In any case, discussing the size of a database or the hardware it runs
on usually isn't as important as how well it has been designed. If you
have a well designed database which is properly indexed and accessed
using well-written code, then it will perform and scale well up to
very large amounts of data. If you don't, then you can have
performance problems with even small amounts of data.

Simon


Jul 20 '05 #11
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.

John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******** *************** *********@4ax.c om...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
dchow <dc***@hotmail. com> wrote in message news:<in******* *************** **********@4ax. com>...
SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
disk. Didn't have the server and CPU model with me.
On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
<da******@x.was hington.edu> wrote:

>dchow wrote:
>
>>Our database size is currently 4G and is incrementing at a rate of
>>45M/day. What is the max size of a SQL database? And what is the
>>size beyond which the server performance will start to go down?
>>


<snip>

Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
that most people will ever need to consider. In practice the
limitations are storage capacity and your ability to manage and
backup/restore the database. A 4GB database is not large, and 45MB per
day is a growth of about 16GB per year - 20GB is not particularly
large either.

It's not possible to say when performance will go down - it depends on
the load you place on the server. You can use Performance Monitor and
other tools to monitor CPU, disk access, memory use etc. to see if
there's a bottleneck somewhere. Having a single 50GB hard drive seems
rather limiting, if that's what you have - disk space is cheap, so
most people can afford to get extra disks and use RAID (or perhaps a
SAN/NAS) to improve performance by spreading the databases across
multiple disks.

In any case, discussing the size of a database or the hardware it runs
on usually isn't as important as how well it has been designed. If you
have a well designed database which is properly indexed and accessed
using well-written code, then it will perform and scale well up to
very large amounts of data. If you don't, then you can have
performance problems with even small amounts of data.

Simon

Jul 20 '05 #12
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.

John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******** *************** *********@4ax.c om...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
dchow <dc***@hotmail. com> wrote in message news:<in******* *************** **********@4ax. com>...
SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
disk. Didn't have the server and CPU model with me.
On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
<da******@x.was hington.edu> wrote:

>dchow wrote:
>
>>Our database size is currently 4G and is incrementing at a rate of
>>45M/day. What is the max size of a SQL database? And what is the
>>size beyond which the server performance will start to go down?
>>


<snip>

Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
that most people will ever need to consider. In practice the
limitations are storage capacity and your ability to manage and
backup/restore the database. A 4GB database is not large, and 45MB per
day is a growth of about 16GB per year - 20GB is not particularly
large either.

It's not possible to say when performance will go down - it depends on
the load you place on the server. You can use Performance Monitor and
other tools to monitor CPU, disk access, memory use etc. to see if
there's a bottleneck somewhere. Having a single 50GB hard drive seems
rather limiting, if that's what you have - disk space is cheap, so
most people can afford to get extra disks and use RAID (or perhaps a
SAN/NAS) to improve performance by spreading the databases across
multiple disks.

In any case, discussing the size of a database or the hardware it runs
on usually isn't as important as how well it has been designed. If you
have a well designed database which is properly indexed and accessed
using well-written code, then it will perform and scale well up to
very large amounts of data. If you don't, then you can have
performance problems with even small amounts of data.

Simon

Jul 20 '05 #13

"John Bell" <jb************ @hotmail.com> wrote in message
news:3f******** **************@ reading.news.pi pex.net...
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.
I personally do not favor shrinking the file. It adds overhead and as it's
just likely to grow again, there's usually not much point.


John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******** *************** *********@4ax.c om...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
dchow <dc***@hotmail. com> wrote in message news:<in******* *************** **********@4ax. com>...> SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
> disk. Didn't have the server and CPU model with me.
>
>
> On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
> <da******@x.was hington.edu> wrote:
>
> >dchow wrote:
> >
> >>Our database size is currently 4G and is incrementing at a rate of
> >>45M/day. What is the max size of a SQL database? And what is the
> >>size beyond which the server performance will start to go down?
> >>

<snip>

Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
that most people will ever need to consider. In practice the
limitations are storage capacity and your ability to manage and
backup/restore the database. A 4GB database is not large, and 45MB per
day is a growth of about 16GB per year - 20GB is not particularly
large either.

It's not possible to say when performance will go down - it depends on
the load you place on the server. You can use Performance Monitor and
other tools to monitor CPU, disk access, memory use etc. to see if
there's a bottleneck somewhere. Having a single 50GB hard drive seems
rather limiting, if that's what you have - disk space is cheap, so
most people can afford to get extra disks and use RAID (or perhaps a
SAN/NAS) to improve performance by spreading the databases across
multiple disks.

In any case, discussing the size of a database or the hardware it runs
on usually isn't as important as how well it has been designed. If you
have a well designed database which is properly indexed and accessed
using well-written code, then it will perform and scale well up to
very large amounts of data. If you don't, then you can have
performance problems with even small amounts of data.

Simon


Jul 20 '05 #14

"John Bell" <jb************ @hotmail.com> wrote in message
news:3f******** **************@ reading.news.pi pex.net...
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.
I personally do not favor shrinking the file. It adds overhead and as it's
just likely to grow again, there's usually not much point.


John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******** *************** *********@4ax.c om...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
dchow <dc***@hotmail. com> wrote in message news:<in******* *************** **********@4ax. com>...> SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
> disk. Didn't have the server and CPU model with me.
>
>
> On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
> <da******@x.was hington.edu> wrote:
>
> >dchow wrote:
> >
> >>Our database size is currently 4G and is incrementing at a rate of
> >>45M/day. What is the max size of a SQL database? And what is the
> >>size beyond which the server performance will start to go down?
> >>

<snip>

Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
that most people will ever need to consider. In practice the
limitations are storage capacity and your ability to manage and
backup/restore the database. A 4GB database is not large, and 45MB per
day is a growth of about 16GB per year - 20GB is not particularly
large either.

It's not possible to say when performance will go down - it depends on
the load you place on the server. You can use Performance Monitor and
other tools to monitor CPU, disk access, memory use etc. to see if
there's a bottleneck somewhere. Having a single 50GB hard drive seems
rather limiting, if that's what you have - disk space is cheap, so
most people can afford to get extra disks and use RAID (or perhaps a
SAN/NAS) to improve performance by spreading the databases across
multiple disks.

In any case, discussing the size of a database or the hardware it runs
on usually isn't as important as how well it has been designed. If you
have a well designed database which is properly indexed and accessed
using well-written code, then it will perform and scale well up to
very large amounts of data. If you don't, then you can have
performance problems with even small amounts of data.

Simon


Jul 20 '05 #15
"Greg D. Moore \(Strider\)" <mo*****@greenm s.com> wrote in message news:<iW******* **********@twis ter.nyroc.rr.co m>...
"John Bell" <jb************ @hotmail.com> wrote in message
news:3f******** **************@ reading.news.pi pex.net...
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.


I personally do not favor shrinking the file. It adds overhead and as it's
just likely to grow again, there's usually not much point.

Hi Greg

It would depend on the circumstances, and data files and log files
would have different criteria. I would say that until the OP is more
experienced the more cautious approach of shrinking the file is the
better approach (IMO). Once he has built up a monitoring mechanism, he
would not have to be a blind approach.

John
Jul 20 '05 #16
We do backup nightly and perform integrity check as well as shrinking
the files weekly.
Does shrinking the database increase overhead like Greg said? I
thought shrinking the database is similar to compacting database in
Access. Is there a compacting process in SQL server?

On Wed, 29 Oct 2003 09:38:01 -0000, "John Bell"
<jb************ @hotmail.com> wrote:
Hi

I don't think anyone has mentioned that you should have a maintenance plan
(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.

John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******* *************** **********@4ax. com...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
>dchow <dc***@hotmail. com> wrote in messagenews:<in****** *************** ***********@4ax .com>... >> SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard
>> disk. Didn't have the server and CPU model with me.
>>
>>
>> On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
>> <da******@x.was hington.edu> wrote:
>>
>> >dchow wrote:
>> >
>> >>Our database size is currently 4G and is incrementing at a rate of
>> >>45M/day. What is the max size of a SQL database? And what is the
>> >>size beyond which the server performance will start to go down?
>> >>
>
><snip>
>
>Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
>that most people will ever need to consider. In practice the
>limitations are storage capacity and your ability to manage and
>backup/restore the database. A 4GB database is not large, and 45MB per
>day is a growth of about 16GB per year - 20GB is not particularly
>large either.
>
>It's not possible to say when performance will go down - it depends on
>the load you place on the server. You can use Performance Monitor and
>other tools to monitor CPU, disk access, memory use etc. to see if
>there's a bottleneck somewhere. Having a single 50GB hard drive seems
>rather limiting, if that's what you have - disk space is cheap, so
>most people can afford to get extra disks and use RAID (or perhaps a
>SAN/NAS) to improve performance by spreading the databases across
>multiple disks.
>
>In any case, discussing the size of a database or the hardware it runs
>on usually isn't as important as how well it has been designed. If you
>have a well designed database which is properly indexed and accessed
>using well-written code, then it will perform and scale well up to
>very large amounts of data. If you don't, then you can have
>performance problems with even small amounts of data.
>
>Simon


Jul 20 '05 #17

"dchow" <dc***@hotmail. com> wrote in message
news:fg******** *************** *********@4ax.c om...
We do backup nightly and perform integrity check as well as shrinking
the files weekly.
Does shrinking the database increase overhead like Greg said? I
thought shrinking the database is similar to compacting database in
Access. Is there a compacting process in SQL server?
No, shrinking the database file merely shrinks the database file.

And this can be a problem for the following reason:

(btw, generally folks shrink the transaction log since that grows and
shrinks a lot).

If you have say two databases on a server:

Both start out with a 25 MB transaction log and grow in 25 MB increments.
(and nightly you shrink it back to 25 MB).

You start out with 200 MB of free disk space, all in one big block.

Log for D1 exceeds 25 MB and grows to 50MB

Ideally this is contiguous space, let's assume it is.

The log for D1 exceeds 50 MB and grows to 75 MB.

This repeats until it reaches 175 MB. So far once nice big contiguous log
file.

Now, D2 exceeds its log of 25 MB and grows. Where's this chunk going to
grow into? The remaining 25 MB of free space. Ok, not, a major problem,
but you've just decreased the likelihood that that space was contiguous with
D2's original log file.

Now, you shrink D1's log back to 25 MB after backing it up.

Meanwhile D2's log grows again. So it's not allocated in the free space
previous used by part of D1's log file. This we already know is not
contiguous to D2's 1st growth. So now D2's log file is spread across 3
separate blocks on the disk.
Now D1's log starts to grow again. It grows into the now free space.
Again, this ends up not being contiguous.

Rinse, lather repeat.

Now, this is a rather derived example and in reality there are things that
will help (the fact that SQL Server will be using virtual logs within your
log file space, you're going to do a lot of linear reads so it'll read all
from one block before moving on, etc.) But, keep in mind that while the
server is expanding the log file, any pending transactions are held up until
the space is allocated since obviously SQL Server can't write them to disk
if the current space is filled.

But, over all, the end effect is you end up with a fragmented log file which
can affect performance.

Is this is a huge problem? Probably not.

But in general you should try to configure your logfiles so they don't need
to expand and shrink.

Do I practice what I preach? Of course not. :-) I have one server that
does nightly rollups. The logfile can expand by a couple of gig overnight
and then shrink again.

Unfortunately, due to lack of enough disk space on this server, I have
another process that runs at a different time that also needs disk space.
So in this case I do compact the transaction log. I'd much rather not
though.
BTW, due to the way SQL Server operates, there's really no exact equivalent
to ACCESS's compaction. However, updating Stats is generally a good idea if
your data changes a lot. And index defrag from time to time might help, but
I don't do that myself. (Though looking into doing it on a few dbs we have.)

Hope that helps.

On Wed, 29 Oct 2003 09:38:01 -0000, "John Bell"
<jb************ @hotmail.com> wrote:
Hi

I don't think anyone has mentioned that you should have a maintenance plan(or equivalent jobs) that backups up the database, checks integrity, and
shrinks the files.

John

If this is in place you should have the ability to recover in case of
disaster and
"dchow" <dc***@hotmail. com> wrote in message
news:bf******* *************** **********@4ax. com...
Thanks Simon. If fact we have RAID. But because I am not a network
admin guy, I didn't know too much about it. All I know was that I have
50G on the data partition. Having learned that 45MB growth per day is
not particularly large made me more comfortable.
On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:

>dchow <dc***@hotmail. com> wrote in message

news:<in****** *************** ***********@4ax .com>...
>> SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSI hard >> disk. Didn't have the server and CPU model with me.
>>
>>
>> On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
>> <da******@x.was hington.edu> wrote:
>>
>> >dchow wrote:
>> >
>> >>Our database size is currently 4G and is incrementing at a rate of
>> >>45M/day. What is the max size of a SQL database? And what is the
>> >>size beyond which the server performance will start to go down?
>> >>
>
><snip>
>
>Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
>that most people will ever need to consider. In practice the
>limitations are storage capacity and your ability to manage and
>backup/restore the database. A 4GB database is not large, and 45MB per
>day is a growth of about 16GB per year - 20GB is not particularly
>large either.
>
>It's not possible to say when performance will go down - it depends on
>the load you place on the server. You can use Performance Monitor and
>other tools to monitor CPU, disk access, memory use etc. to see if
>there's a bottleneck somewhere. Having a single 50GB hard drive seems
>rather limiting, if that's what you have - disk space is cheap, so
>most people can afford to get extra disks and use RAID (or perhaps a
>SAN/NAS) to improve performance by spreading the databases across
>multiple disks.
>
>In any case, discussing the size of a database or the hardware it runs
>on usually isn't as important as how well it has been designed. If you
>have a well designed database which is properly indexed and accessed
>using well-written code, then it will perform and scale well up to
>very large amounts of data. If you don't, then you can have
>performance problems with even small amounts of data.
>
>Simon

Jul 20 '05 #18
There is no such concept... u need to have sufficient hard drive
space... SQL 2000 can handle any size...

Even in TB

Keyur Shah
Verizon Communications
732-423-0745

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 20 '05 #19
Greg, thanks for the detailed explanation. As I am not a network
adminstrator, I might not know something that a network admin should.
Appreciate if you could tell me how to:
- Configure the logfiles so they don't need to expand and shrink.
- Update Stats.
- Index defrag.

And, do you actually recommend doing shrinking?

Thanks
David
On Wed, 05 Nov 2003 04:16:38 GMT, "Greg D. Moore \(Strider\)"
<mo*****@greenm s.com> wrote:

"dchow" <dc***@hotmail. com> wrote in message
news:fg******* *************** **********@4ax. com...
We do backup nightly and perform integrity check as well as shrinking
the files weekly.
Does shrinking the database increase overhead like Greg said? I
thought shrinking the database is similar to compacting database in
Access. Is there a compacting process in SQL server?


No, shrinking the database file merely shrinks the database file.

And this can be a problem for the following reason:

(btw, generally folks shrink the transaction log since that grows and
shrinks a lot).

If you have say two databases on a server:

Both start out with a 25 MB transaction log and grow in 25 MB increments.
(and nightly you shrink it back to 25 MB).

You start out with 200 MB of free disk space, all in one big block.

Log for D1 exceeds 25 MB and grows to 50MB

Ideally this is contiguous space, let's assume it is.

The log for D1 exceeds 50 MB and grows to 75 MB.

This repeats until it reaches 175 MB. So far once nice big contiguous log
file.

Now, D2 exceeds its log of 25 MB and grows. Where's this chunk going to
grow into? The remaining 25 MB of free space. Ok, not, a major problem,
but you've just decreased the likelihood that that space was contiguous with
D2's original log file.

Now, you shrink D1's log back to 25 MB after backing it up.

Meanwhile D2's log grows again. So it's not allocated in the free space
previous used by part of D1's log file. This we already know is not
contiguous to D2's 1st growth. So now D2's log file is spread across 3
separate blocks on the disk.
Now D1's log starts to grow again. It grows into the now free space.
Again, this ends up not being contiguous.

Rinse, lather repeat.

Now, this is a rather derived example and in reality there are things that
will help (the fact that SQL Server will be using virtual logs within your
log file space, you're going to do a lot of linear reads so it'll read all
from one block before moving on, etc.) But, keep in mind that while the
server is expanding the log file, any pending transactions are held up until
the space is allocated since obviously SQL Server can't write them to disk
if the current space is filled.

But, over all, the end effect is you end up with a fragmented log file which
can affect performance.

Is this is a huge problem? Probably not.

But in general you should try to configure your logfiles so they don't need
to expand and shrink.

Do I practice what I preach? Of course not. :-) I have one server that
does nightly rollups. The logfile can expand by a couple of gig overnight
and then shrink again.

Unfortunatel y, due to lack of enough disk space on this server, I have
another process that runs at a different time that also needs disk space.
So in this case I do compact the transaction log. I'd much rather not
though.
BTW, due to the way SQL Server operates, there's really no exact equivalent
to ACCESS's compaction. However, updating Stats is generally a good idea if
your data changes a lot. And index defrag from time to time might help, but
I don't do that myself. (Though looking into doing it on a few dbs we have.)

Hope that helps.

On Wed, 29 Oct 2003 09:38:01 -0000, "John Bell"
<jb************ @hotmail.com> wrote:
>Hi
>
>I don't think anyone has mentioned that you should have a maintenanceplan >(or equivalent jobs) that backups up the database, checks integrity, and
>shrinks the files.
>
>John
>
>If this is in place you should have the ability to recover in case of
>disaster and
>"dchow" <dc***@hotmail. com> wrote in message
>news:bf******* *************** **********@4ax. com...
>> Thanks Simon. If fact we have RAID. But because I am not a network
>> admin guy, I didn't know too much about it. All I know was that I have
>> 50G on the data partition. Having learned that 45MB growth per day is
>> not particularly large made me more comfortable.
>>
>>
>> On 28 Oct 2003 01:01:20 -0800, sq*@hayes.ch (Simon Hayes) wrote:
>>
>> >dchow <dc***@hotmail. com> wrote in message
>news:<in****** *************** ***********@4ax .com>...
>> >> SQL server 2000 on IBM server with quad CPU, 4G memory, 50G SCSIhard >> >> disk. Didn't have the server and CPU model with me.
>> >>
>> >>
>> >> On Mon, 27 Oct 2003 15:41:17 -0800, Daniel Morgan
>> >> <da******@x.was hington.edu> wrote:
>> >>
>> >> >dchow wrote:
>> >> >
>> >> >>Our database size is currently 4G and is incrementing at a rate of
>> >> >>45M/day. What is the max size of a SQL database? And what is the
>> >> >>size beyond which the server performance will start to go down?
>> >> >>
>> >
>> ><snip>
>> >
>> >Maximum DB size in MSSQL is over 1,000,000TB, so it's not something
>> >that most people will ever need to consider. In practice the
>> >limitations are storage capacity and your ability to manage and
>> >backup/restore the database. A 4GB database is not large, and 45MB per
>> >day is a growth of about 16GB per year - 20GB is not particularly
>> >large either.
>> >
>> >It's not possible to say when performance will go down - it depends on
>> >the load you place on the server. You can use Performance Monitor and
>> >other tools to monitor CPU, disk access, memory use etc. to see if
>> >there's a bottleneck somewhere. Having a single 50GB hard drive seems
>> >rather limiting, if that's what you have - disk space is cheap, so
>> >most people can afford to get extra disks and use RAID (or perhaps a
>> >SAN/NAS) to improve performance by spreading the databases across
>> >multiple disks.
>> >
>> >In any case, discussing the size of a database or the hardware it runs
>> >on usually isn't as important as how well it has been designed. If you
>> >have a well designed database which is properly indexed and accessed
>> >using well-written code, then it will perform and scale well up to
>> >very large amounts of data. If you don't, then you can have
>> >performance problems with even small amounts of data.
>> >
>> >Simon
>>
>


Jul 20 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
8230
by: Robin Tucker | last post by:
As I had real problems working my head around sp_spaceused, I've written an SP to do it (I also noted a lot of questions about this when "searching"). Pass in a database name and it will return the size of the database as a float (ie. 0.75 for 0.75mb). Update usage set to 1 indicates the DB should update its size information before giving you the result. Anyway, comments appreciate. ALTER PROCEDURE dbo.proc_BL_Get_Space_Used
2
5283
by: Sue | last post by:
I have a large database currently using up 30GB of space -- problem is, I am running out of space on my harddrive and so have to do some cleanup. One of the tables has a blob field and I find that I can safely delete some of this blob data because I will not be needing it in the database anymore. So the question is, if I delete some of the blob data from this table will the database size decrease? Is there anything else I can do to...
6
5124
by: DH | last post by:
I have a VERY basic question about figuring database size. I've inherited a database which is generally similar to this basic one: Item, Red, Blue, Green, Yellow (text), (int),(int),(int),(int) box, 1,0,0,2 hat, 0,0,0,1 car, 3,0,0,0 This format leads to a lot of zeros in the rows which take up a lot of
7
1904
by: perspolis | last post by:
hi I have two table named Purchase and Sale..all of fields of both tables are the same...I make them design in one table with an additional boolean field to determine which is Sale and Purchase... it is good to design them in seperate tables without additional field?? or design both in one table...
4
1578
by: cover | last post by:
I have two distinctively different pieces of equipment that I'm trying to build a database for, each having 20 inputs which makes my mysql table 40 fields wide. Form one is for 'shakers' and form two is for 'conveyors'. About the only thing they will have in common is that they both share 'motorsize' and they both share 'bearing' although shakers have two where conveyors have four. I'd first built a table within a database called...
4
8202
by: vijay.db | last post by:
Hi Group, It's really confusing to calculate the size of the DB2 UDB database in versions lesser than 8.2. In Version 8.2 if we run the query db2 "call get_dbsize_info(?,?,?,0)" it gives us an approximate size of the database. But it we try calculating the file system sizes of the database home directory, containers file system it gives some other size...
0
1770
by: VIPS | last post by:
On Apr 3, 7:29 am, "Krisnamourt via SQLMonster.com" <u21487@uwe> wrote: REGARDING TEMP DB SIZE: -For a small db server that does about 10-20 GB of logging per day, I would recommend having a size that does not go through AUTO_GROW. i.e ensure that the size of tempdb is big enough that it will hold the whole days work.
5
13094
by: aleu | last post by:
Hi all, Could you please advise whether there are documents describing impact of MS SQL server 2005 database size on its performance? I have essentially two things in mind when writing the "database size": 1.) number of records stored within the database (e.g. one customer's account with 5,000 records vs. another account with 500,000 records.) 2.) physical database size (amount of data written to a disk volume) - e.g. one database of...
1
1804
by: rednemesis | last post by:
Good Day everyone! When I calculated the size of the database on my system using the formula: Total Page size x Page size (4096) = Total Database Size Used page size x Page size (4096) = Total Used Page Size I then add up the results from all the tablespaces. My question is, with the result, why is the size of Total Database Size and Total Used Page size is larger than the disk space size from the command 'df' in linux.
0
9969
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9810
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11203
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10794
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10443
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9612
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7999
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5830
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4251
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.