Database size

Hi all,
I need to estimate the disk space required for SQL Server
2000 and our application databases. Apart from the
table/index sizes (calculated as per logic given in BOL),
are there any other parameters to be considered to size
the disks ? Like more space for tempdb?
Is there any standard approach to estimate the disk space
required based on data growth?
Thanks,
HariHi Hari
Yes, the transaction log is a significant consideration. It is not possible
to accurately calculate size requirements for log space / growth as the log
storage format is not even published. Best bet with this is to make regular
observations, collect empirical data on growth rates between backup windows
& ensure you have enough space for log use / growth.
There's information on calculating database size in Books Online at:
http://msdn.microsoft.com/library/e...des_02_2h45.asp
The topic's also covered widely in books, including:
http://www.microsoft.com/mspress/bo...TableOfContents
HTH
Regards,
Greg Linwood
SQL Server MVP
"Hari" <anonymous@.discussions.microsoft.com> wrote in message
news:295d801c464af$6021d1a0$a301280a@.phx
.gbl...
> Hi all,
> I need to estimate the disk space required for SQL Server
> 2000 and our application databases. Apart from the
> table/index sizes (calculated as per logic given in BOL),
> are there any other parameters to be considered to size
> the disks ? Like more space for tempdb?
> Is there any standard approach to estimate the disk space
> required based on data growth?
> Thanks,
> Hari

Database size

Hi all,
I need to estimate the disk space required for SQL Server
2000 and our application databases. Apart from the
table/index sizes (calculated as per logic given in BOL),
are there any other parameters to be considered to size
the disks ? Like more space for tempdb?
Is there any standard approach to estimate the disk space
required based on data growth?
Thanks,
HariHi Hari
Yes, the transaction log is a significant consideration. It is not possible
to accurately calculate size requirements for log space / growth as the log
storage format is not even published. Best bet with this is to make regular
observations, collect empirical data on growth rates between backup windows
& ensure you have enough space for log use / growth.
There's information on calculating database size in Books Online at:
http://msdn.microsoft.com/library/en-us/createdb/cm_8_des_02_2h45.asp
The topic's also covered widely in books, including:
http://www.microsoft.com/mspress/books/toc/4944.asp#TableOfContents
HTH
Regards,
Greg Linwood
SQL Server MVP
"Hari" <anonymous@.discussions.microsoft.com> wrote in message
news:295d801c464af$6021d1a0$a301280a@.phx.gbl...
> Hi all,
> I need to estimate the disk space required for SQL Server
> 2000 and our application databases. Apart from the
> table/index sizes (calculated as per logic given in BOL),
> are there any other parameters to be considered to size
> the disks ? Like more space for tempdb?
> Is there any standard approach to estimate the disk space
> required based on data growth?
> Thanks,
> Hari

Database size

Hi all,
I need to estimate the disk space required for SQL Server
2000 and our application databases. Apart from the
table/index sizes (calculated as per logic given in BOL),
are there any other parameters to be considered to size
the disks ? Like more space for tempdb?
Is there any standard approach to estimate the disk space
required based on data growth?
Thanks,
Hari
Hi Hari
Yes, the transaction log is a significant consideration. It is not possible
to accurately calculate size requirements for log space / growth as the log
storage format is not even published. Best bet with this is to make regular
observations, collect empirical data on growth rates between backup windows
& ensure you have enough space for log use / growth.
There's information on calculating database size in Books Online at:
http://msdn.microsoft.com/library/en...es_02_2h45.asp
The topic's also covered widely in books, including:
http://www.microsoft.com/mspress/boo...ableOfContents
HTH
Regards,
Greg Linwood
SQL Server MVP
"Hari" <anonymous@.discussions.microsoft.com> wrote in message
news:295d801c464af$6021d1a0$a301280a@.phx.gbl...
> Hi all,
> I need to estimate the disk space required for SQL Server
> 2000 and our application databases. Apart from the
> table/index sizes (calculated as per logic given in BOL),
> are there any other parameters to be considered to size
> the disks ? Like more space for tempdb?
> Is there any standard approach to estimate the disk space
> required based on data growth?
> Thanks,
> Hari

Database Replication

We currently have multiple tables being replicated using merge snapshot. In
the majority of cases the whole table is required or a row filter is applied
based on a value in that table.
We have two sets of identical databases, except for their data, that
replicate their data from a backend database towards a frontend database.
The problem is that for database 1, all the necesarry data is replicated,
but for the other database 2, which has the same parameters, replication
settings etc.. certain blob files containing pdf files will not replicate
from the backend database towards the frontend database.
The replication only replicates the .doc files, so the replication is
partially done for the table that contains the .doc and .pdf files.
When I run the initial snapshot, the pdf files are replicated fine, but when
the agent runs, the pdf files are not replicated.
Has anyone encountered similar problems? Can someone identify what is
causing the problem by explaining why this is not working? My first idea
would be the sheduling the snapshot to run every night, instead of the
agent, but this would be a far from ideal solution and one that I would only
consider as a last choice. I fail to understand why the replication works
for database 1, but not for database 2.
parnold8104@.hotmail.com
can you run this command sp_configure 'max text repl size'
and then figure out what your maximum data size in the blob columns you are
replicating?
"Peter A" <parnold8104@.hotmail.com> wrote in message
news:%23sFpoRuJEHA.2456@.TK2MSFTNGP12.phx.gbl...
> We currently have multiple tables being replicated using merge snapshot.
In
> the majority of cases the whole table is required or a row filter is
applied
> based on a value in that table.
> We have two sets of identical databases, except for their data, that
> replicate their data from a backend database towards a frontend database.
> The problem is that for database 1, all the necesarry data is replicated,
> but for the other database 2, which has the same parameters, replication
> settings etc.. certain blob files containing pdf files will not replicate
> from the backend database towards the frontend database.
> The replication only replicates the .doc files, so the replication is
> partially done for the table that contains the .doc and .pdf files.
> When I run the initial snapshot, the pdf files are replicated fine, but
when
> the agent runs, the pdf files are not replicated.
> Has anyone encountered similar problems? Can someone identify what is
> causing the problem by explaining why this is not working? My first idea
> would be the sheduling the snapshot to run every night, instead of the
> agent, but this would be a far from ideal solution and one that I would
only
> consider as a last choice. I fail to understand why the replication works
> for database 1, but not for database 2.
> parnold8104@.hotmail.com
>
>
|||Hi Hilary,
thanks for replying, when I run the command sp_configure I get these values:
max text repl size (B) minimum: 0
maximum: 2147483647
config_value: 52428800
run_value: 52428800
I am not sure if the data size is the problem, because the .doc files that
are replicated are larger in size then the pdf files. Another thing I
noticed is that I can replicate my pdf records in the 'faulty' database, but
only if I do an update of the record in my backend database. So when the
record is 'new' the replication skips it, but if I update the record, by for
example changing a letter in a description field, the replication picks up
the record and pushes it towards the frontend database.
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:eJKebhuJEHA.3592@.TK2MSFTNGP09.phx.gbl...
> can you run this command sp_configure 'max text repl size'
> and then figure out what your maximum data size in the blob columns you
are[vbcol=seagreen]
> replicating?
> "Peter A" <parnold8104@.hotmail.com> wrote in message
> news:%23sFpoRuJEHA.2456@.TK2MSFTNGP12.phx.gbl...
> In
> applied
database.[vbcol=seagreen]
replicated,[vbcol=seagreen]
replicate[vbcol=seagreen]
> when
> only
works
>
|||can you post your schema and publication scripts here?
What version of SQL are you using? SP?
"Peter A" <parnold8104@.hotmail.com> wrote in message
news:%23whCdr3JEHA.232@.TK2MSFTNGP12.phx.gbl...
> Hi Hilary,
> thanks for replying, when I run the command sp_configure I get these
values:
> max text repl size (B) minimum: 0
> maximum: 2147483647
> config_value: 52428800
> run_value: 52428800
> I am not sure if the data size is the problem, because the .doc files that
> are replicated are larger in size then the pdf files. Another thing I
> noticed is that I can replicate my pdf records in the 'faulty' database,
but
> only if I do an update of the record in my backend database. So when the
> record is 'new' the replication skips it, but if I update the record, by
for[vbcol=seagreen]
> example changing a letter in a description field, the replication picks up
> the record and pushes it towards the frontend database.
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:eJKebhuJEHA.3592@.TK2MSFTNGP09.phx.gbl...
> are
snapshot.[vbcol=seagreen]
> database.
> replicated,
replication[vbcol=seagreen]
> replicate
but[vbcol=seagreen]
idea[vbcol=seagreen]
would
> works
>