I am looking to extend some customer data from my SQL Server out to the Web.
I am looking for the best utility to help create these pages\sites quickly.
We are running SQL Server 2000 and IIS 5.0
Thanks..Ted,
Refer sp_makewebtask in BooksOnLine.
--
Dinesh.
SQL Server FAQ at
http://www.tkdinesh.com
"Ted Appleberry" <ted@.appleberry.com> wrote in message
news:efO3YkNQDHA.2832@.TK2MSFTNGP10.phx.gbl...
> I am looking to extend some customer data from my SQL Server out to the
Web.
> I am looking for the best utility to help create these pages\sites
quickly.
> We are running SQL Server 2000 and IIS 5.0
> Thanks..
>|||You could use free community supported tool Web Matrix.
http://www.asp.net/webmatrix/default.aspx?tabindex=4&tabid=46
Thanks
sethu
"Ted Appleberry" <ted@.appleberry.com> wrote in message
news:OgY8aHOQDHA.1752@.TK2MSFTNGP12.phx.gbl...
> I am looking for a nice drag and drop interface or something. Third
Party..
> Don't mind spending $$$. Don't want to write a bunch of code if I can
avoid
> it.. Yes, I know.. I am a wimp..
> "Dinesh.T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:eN3$erNQDHA.1988@.TK2MSFTNGP12.phx.gbl...
> > Ted,
> >
> > Refer sp_makewebtask in BooksOnLine.
> >
> > --
> > Dinesh.
> > SQL Server FAQ at
> > http://www.tkdinesh.com
> >
> > "Ted Appleberry" <ted@.appleberry.com> wrote in message
> > news:efO3YkNQDHA.2832@.TK2MSFTNGP10.phx.gbl...
> > > I am looking to extend some customer data from my SQL Server out to
the
> > Web.
> > > I am looking for the best utility to help create these pages\sites
> > quickly.
> > > We are running SQL Server 2000 and IIS 5.0
> > > Thanks..
> > >
> > >
> >
> >
>
Showing posts with label pages. Show all posts
Showing posts with label pages. Show all posts
Thursday, March 29, 2012
Sunday, March 11, 2012
Best practice for shrinking Databases
Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
Dan
In general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan
|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com... [vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
Dan
In general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan
|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com... [vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Best practice for shrinking Databases
Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages t
o
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.
4ax.com...[vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages t
o
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.
4ax.com...[vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Best practice for shrinking Databases
Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com...
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>>Is there a "best practice" for shrinking databases?
>>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages
>>to
>>the beginning before shrinking?
>>I already have Maintenance Plans to backup logs and the database etc. but
>>wondered about automating the shrink process as well. There seems to be
>>alot of free space 67%+ in the database and logfile.
>>Dan|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com...
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>>Is there a "best practice" for shrinking databases?
>>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages
>>to
>>the beginning before shrinking?
>>I already have Maintenance Plans to backup logs and the database etc. but
>>wondered about automating the shrink process as well. There seems to be
>>alot of free space 67%+ in the database and logfile.
>>Dan|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan
Subscribe to:
Posts (Atom)