LIMIT problems: log

Showing posts with label log. Show all posts

Monday, March 12, 2012

Limiting transaction Log file size

Please forgive my inability to fully comprehend this topic. I have posted
other messages regarding similar file issues and followed the
recommendations under the message topic SQL Server 2k transaction log file
I have a transaction file that is set to unlimited growth. as of now it is
about 8.5GB. I want the file to be smaller.
I have successfully backed up the log, shrunk the file down to 700MB, and
changed the log method to simple recovery.
The problem is the file allocation is still at the 8.5GB and when I try and
change the file growth restriction to say 2.5GB, SQL will not allow the
growth restriction to be less than the allocated space (8.5GB).
Is there a way to change the allocated space and/or the file growth
restriction size?
I hope my scenario is clear.
WBSee http://www.karaszi.com/SQLServer/info_dont_shrink.asp for details on shrinking transaction log
files.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"WB" <none> wrote in message news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
> Please forgive my inability to fully comprehend this topic. I have posted
> other messages regarding similar file issues and followed the
> recommendations under the message topic SQL Server 2k transaction log file
> I have a transaction file that is set to unlimited growth. as of now it is
> about 8.5GB. I want the file to be smaller.
> I have successfully backed up the log, shrunk the file down to 700MB, and
> changed the log method to simple recovery.
> The problem is the file allocation is still at the 8.5GB and when I try and
> change the file growth restriction to say 2.5GB, SQL will not allow the
> growth restriction to be less than the allocated space (8.5GB).
> Is there a way to change the allocated space and/or the file growth
> restriction size?
> I hope my scenario is clear.
> WB
>|||Thank you for you response. I have re-examined your link and still do not
find the answer. the information you provided relates to shrinking the
file, which I have completed.
I want to change the amount of space allocated in the transaction log file.
It is to big at 8.5GB and I want it to be a maximum of 2.5GB.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%231j0aRmYGHA.3424@.TK2MSFTNGP02.phx.gbl...
> See http://www.karaszi.com/SQLServer/info_dont_shrink.asp for details on
shrinking transaction log
> files.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "WB" <none> wrote in message news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
> > Please forgive my inability to fully comprehend this topic. I have
posted
> > other messages regarding similar file issues and followed the
> > recommendations under the message topic SQL Server 2k transaction log
file
> >
> > I have a transaction file that is set to unlimited growth. as of now it
is
> > about 8.5GB. I want the file to be smaller.
> >
> > I have successfully backed up the log, shrunk the file down to 700MB,
and
> > changed the log method to simple recovery.
> >
> > The problem is the file allocation is still at the 8.5GB and when I try
and
> > change the file growth restriction to say 2.5GB, SQL will not allow the
> > growth restriction to be less than the allocated space (8.5GB).
> >
> > Is there a way to change the allocated space and/or the file growth
> > restriction size?
> >
> > I hope my scenario is clear.
> >
> > WB
> >
> >
>|||I'm afraid I don't follow you...
You say that file is 700MB. How did you determine that number?
You also say that the file allocation is 8.5GB. I fail to see how the allocation is larger than the
file size. Where did you see this number? Or did you mean the max file size?
For the above two numbers, use DBCC SQLPERF(LOGSPACE)
How do you try to change the max file size? You can try ALTER DATABASE ... MODIFY FILE, perhaps the
GUI is doing something strange...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"WB" <none> wrote in message news:eN$AGemYGHA.3516@.TK2MSFTNGP03.phx.gbl...
> Thank you for you response. I have re-examined your link and still do not
> find the answer. the information you provided relates to shrinking the
> file, which I have completed.
> I want to change the amount of space allocated in the transaction log file.
> It is to big at 8.5GB and I want it to be a maximum of 2.5GB.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:%231j0aRmYGHA.3424@.TK2MSFTNGP02.phx.gbl...
>> See http://www.karaszi.com/SQLServer/info_dont_shrink.asp for details on
> shrinking transaction log
>> files.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>> Blog: http://solidqualitylearning.com/blogs/tibor/
>>
>> "WB" <none> wrote in message news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
>> > Please forgive my inability to fully comprehend this topic. I have
> posted
>> > other messages regarding similar file issues and followed the
>> > recommendations under the message topic SQL Server 2k transaction log
> file
>> >
>> > I have a transaction file that is set to unlimited growth. as of now it
> is
>> > about 8.5GB. I want the file to be smaller.
>> >
>> > I have successfully backed up the log, shrunk the file down to 700MB,
> and
>> > changed the log method to simple recovery.
>> >
>> > The problem is the file allocation is still at the 8.5GB and when I try
> and
>> > change the file growth restriction to say 2.5GB, SQL will not allow the
>> > growth restriction to be less than the allocated space (8.5GB).
>> >
>> > Is there a way to change the allocated space and/or the file growth
>> > restriction size?
>> >
>> > I hope my scenario is clear.
>> >
>> > WB
>> >
>> >
>|||Its still not very clear what you have done so far. You can shrink the log
file, disable the auto grow and turn on "truncate log on checkpoint".
Jayesh
"WB" <none> wrote in message news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
> Please forgive my inability to fully comprehend this topic. I have posted
> other messages regarding similar file issues and followed the
> recommendations under the message topic SQL Server 2k transaction log file
> I have a transaction file that is set to unlimited growth. as of now it
> is
> about 8.5GB. I want the file to be smaller.
> I have successfully backed up the log, shrunk the file down to 700MB, and
> changed the log method to simple recovery.
> The problem is the file allocation is still at the 8.5GB and when I try
> and
> change the file growth restriction to say 2.5GB, SQL will not allow the
> growth restriction to be less than the allocated space (8.5GB).
> Is there a way to change the allocated space and/or the file growth
> restriction size?
> I hope my scenario is clear.
> WB
>|||I was deriving my numbers from Enterprise Manager by looking at the
properties of the database.
When I try your suggested method the result is the same. It shows the log
size in MB as being 8,415 and the % of space used as 8.7. This would seem
to translate to the numbers I provided.
Yes, what I want to do is change the max file size.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:ObZ3b%23qYGHA.4760@.TK2MSFTNGP03.phx.gbl...
> I'm afraid I don't follow you...
> You say that file is 700MB. How did you determine that number?
> You also say that the file allocation is 8.5GB. I fail to see how the
allocation is larger than the
> file size. Where did you see this number? Or did you mean the max file
size?
> For the above two numbers, use DBCC SQLPERF(LOGSPACE)
> How do you try to change the max file size? You can try ALTER DATABASE ...
MODIFY FILE, perhaps the
> GUI is doing something strange...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "WB" <none> wrote in message news:eN$AGemYGHA.3516@.TK2MSFTNGP03.phx.gbl...
> > Thank you for you response. I have re-examined your link and still do
not
> > find the answer. the information you provided relates to shrinking the
> > file, which I have completed.
> >
> > I want to change the amount of space allocated in the transaction log
file.
> > It is to big at 8.5GB and I want it to be a maximum of 2.5GB.
> >
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> > message news:%231j0aRmYGHA.3424@.TK2MSFTNGP02.phx.gbl...
> >> See http://www.karaszi.com/SQLServer/info_dont_shrink.asp for details
on
> > shrinking transaction log
> >> files.
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://www.solidqualitylearning.com/
> >> Blog: http://solidqualitylearning.com/blogs/tibor/
> >>
> >>
> >> "WB" <none> wrote in message
news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
> >> > Please forgive my inability to fully comprehend this topic. I have
> > posted
> >> > other messages regarding similar file issues and followed the
> >> > recommendations under the message topic SQL Server 2k transaction log
> > file
> >> >
> >> > I have a transaction file that is set to unlimited growth. as of now
it
> > is
> >> > about 8.5GB. I want the file to be smaller.
> >> >
> >> > I have successfully backed up the log, shrunk the file down to 700MB,
> > and
> >> > changed the log method to simple recovery.
> >> >
> >> > The problem is the file allocation is still at the 8.5GB and when I
try
> > and
> >> > change the file growth restriction to say 2.5GB, SQL will not allow
the
> >> > growth restriction to be less than the allocated space (8.5GB).
> >> >
> >> > Is there a way to change the allocated space and/or the file growth
> >> > restriction size?
> >> >
> >> > I hope my scenario is clear.
> >> >
> >> > WB
> >> >
> >> >
> >>
> >
> >
>|||So the current size it 8,415 and utilization it 8.7%. To shrink the file size, see
http://www.karaszi.com/SQLServer/info_dont_shrink.asp. You can then set a max size, but is more than
that is needed, the modifications will fail.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"WB" <none> wrote in message news:uvT8UvwYGHA.1888@.TK2MSFTNGP02.phx.gbl...
>I was deriving my numbers from Enterprise Manager by looking at the
> properties of the database.
> When I try your suggested method the result is the same. It shows the log
> size in MB as being 8,415 and the % of space used as 8.7. This would seem
> to translate to the numbers I provided.
> Yes, what I want to do is change the max file size.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:ObZ3b%23qYGHA.4760@.TK2MSFTNGP03.phx.gbl...
>> I'm afraid I don't follow you...
>> You say that file is 700MB. How did you determine that number?
>> You also say that the file allocation is 8.5GB. I fail to see how the
> allocation is larger than the
>> file size. Where did you see this number? Or did you mean the max file
> size?
>> For the above two numbers, use DBCC SQLPERF(LOGSPACE)
>> How do you try to change the max file size? You can try ALTER DATABASE ...
> MODIFY FILE, perhaps the
>> GUI is doing something strange...
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "WB" <none> wrote in message news:eN$AGemYGHA.3516@.TK2MSFTNGP03.phx.gbl...
>> > Thank you for you response. I have re-examined your link and still do
> not
>> > find the answer. the information you provided relates to shrinking the
>> > file, which I have completed.
>> >
>> > I want to change the amount of space allocated in the transaction log
> file.
>> > It is to big at 8.5GB and I want it to be a maximum of 2.5GB.
>> >
>> > "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in
>> > message news:%231j0aRmYGHA.3424@.TK2MSFTNGP02.phx.gbl...
>> >> See http://www.karaszi.com/SQLServer/info_dont_shrink.asp for details
> on
>> > shrinking transaction log
>> >> files.
>> >>
>> >> --
>> >> Tibor Karaszi, SQL Server MVP
>> >> http://www.karaszi.com/sqlserver/default.asp
>> >> http://www.solidqualitylearning.com/
>> >> Blog: http://solidqualitylearning.com/blogs/tibor/
>> >>
>> >>
>> >> "WB" <none> wrote in message
> news:eQ9vVNmYGHA.1200@.TK2MSFTNGP03.phx.gbl...
>> >> > Please forgive my inability to fully comprehend this topic. I have
>> > posted
>> >> > other messages regarding similar file issues and followed the
>> >> > recommendations under the message topic SQL Server 2k transaction log
>> > file
>> >> >
>> >> > I have a transaction file that is set to unlimited growth. as of now
> it
>> > is
>> >> > about 8.5GB. I want the file to be smaller.
>> >> >
>> >> > I have successfully backed up the log, shrunk the file down to 700MB,
>> > and
>> >> > changed the log method to simple recovery.
>> >> >
>> >> > The problem is the file allocation is still at the 8.5GB and when I
> try
>> > and
>> >> > change the file growth restriction to say 2.5GB, SQL will not allow
> the
>> >> > growth restriction to be less than the allocated space (8.5GB).
>> >> >
>> >> > Is there a way to change the allocated space and/or the file growth
>> >> > restriction size?
>> >> >
>> >> > I hope my scenario is clear.
>> >> >
>> >> > WB
>> >> >
>> >> >
>> >>
>> >
>> >
>

Limiting transaction Log file size

Limiting size of a table in SQL server

hi,

im doing network monitoring app where basically i run a checks on servers every few minutes and log the data to a table. Naturally the table can get big, quite quickly. What I want is to be able to overwrite the table data at the start of each new day. Alternatively, rollup the data into a daily or weekly packets and then overwrite table data. How do i do this?Using a scheduled job in SQL Server would likely be the easiest. Create the code to do what you want in a stored procedure, and then schedule the stored procedure.

In Enterprise Manager, expand the database till you see Management, expand that and right click on Jobs below it and select New Job to create and schedule the job.

Friday, March 9, 2012

Limiting log growth during DTS Package

Main DW: DwSQL
Staging Area: DwLoadAreaSQL

The DW is about 60 Gigs. The Staging Area is about 80 Gigs. This is
all good.

However, the log file for the staging area is 50 Gigs and I'm trying
to find ways to not require such a large log file. I tried adding a
few "BACKUP LOG DwLoadAreaSQL WITH TRUNCATE_ONLY" statements in the
DTS package but figured out that because it's 1 DTS package it's all 1
transaction. I've thought about breaking it up into multiple DTS
packages and truncating the log between running them but was hoping to
avoid this. To be clear, I know how to shrink DB's and Log
Files...that's not the issue.

Any Ideas? Thanks.On Jul 24, 3:49 pm, davisutt <davis...@.aol.comwrote:

Quote:

Originally Posted by

SQL Server 2000 SP4. I built a large DTS package that grabs a number
of tables from an Oracle DB, does some scrubbing and date verification
and loads to a SQL Server DB. Most of the tables are full refresh and
a few are incremental.
>
Main DW: DwSQL
Staging Area: DwLoadAreaSQL
>
The DW is about 60 Gigs. The Staging Area is about 80 Gigs. This is
all good.
>
However, the log file for the staging area is 50 Gigs and I'm trying
to find ways to not require such a large log file. I tried adding a
few "BACKUP LOG DwLoadAreaSQL WITH TRUNCATE_ONLY" statements in the
DTS package but figured out that because it's 1 DTS package it's all 1
transaction. I've thought about breaking it up into multiple DTS
packages and truncating the log between running them but was hoping to
avoid this. To be clear, I know how to shrink DB's and Log
Files...that's not the issue.
>
Any Ideas? Thanks.

Make sure both databases are in bulked log recovery mode. You should
have a step at the end of your DTS to run CHECKPOINT, backup truncate
the log. Also, manaually shrink the log file to your desired log size.

Hope it helps...

MNDBA|||On Jul 28, 4:55 pm, kmounkh...@.gmail.com wrote:

Quote:

Originally Posted by

On Jul 24, 3:49 pm, davisutt <davis...@.aol.comwrote:
>
>
>
>
>

Quote:

Originally Posted by

Quote:

Originally Posted by

Main DW: DwSQL
Staging Area: DwLoadAreaSQL

Quote:

Originally Posted by

The DW is about 60 Gigs. The Staging Area is about 80 Gigs. This is
all good.

Quote:

Originally Posted by

Quote:

Originally Posted by

Any Ideas? Thanks.

>
Make sure both databases are in bulked log recovery mode. You should
have a step at the end of your DTS to run CHECKPOINT, backup truncate
the log. Also, manaually shrink the log file to your desired log size.
>
Hope it helps...
>
MNDBA- Hide quoted text -
>
- Show quoted text -

Thanks. I think that's what I was looking for. I changed the
recovery mode and shrunk the log size to about 20% of what it was.
I'll run the process and see what kind of growth occurs.

Limiting job history in SQL2005

Hi,
Under SQL Agent properties/History there are 2 limiting columns for Limit
size of job history log.
We have Maximum job history set to 12000 and maximum job history rows per
job at 150 but we only seem to be able to keep 2 or 3 days worth of
jobhistory even though looking in sysjobhistory I can only return 7300 rows.
I thought that it would keep a maximum of 150 per job to a total of 12000.
Is something else limiting the data in sysjobhistory?
Thanks
ChrisHi,
We found the problem. If you run a maintenance plan that has a History
Cleanup Task and its run by an admin level account then the
sp_purge_jobhistory does not include a @.job_name parameter. This combination
means that all job history gets cleaned up rather than just the job that has
the History Cleanup Task problem raised on Connect as bug 322320.
Chris
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
> Hi,
> Under SQL Agent properties/History there are 2 limiting columns for Limit
> size of job history log.
> We have Maximum job history set to 12000 and maximum job history rows per
> job at 150 but we only seem to be able to keep 2 or 3 days worth of
> jobhistory even though looking in sysjobhistory I can only return 7300
> rows.
> I thought that it would keep a maximum of 150 per job to a total of 12000.
> Is something else limiting the data in sysjobhistory?
> Thanks
> Chris
>|||Very interesting Chris. Thanks for the update.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
> Hi,
> We found the problem. If you run a maintenance plan that has a History
> Cleanup Task and its run by an admin level account then the
> sp_purge_jobhistory does not include a @.job_name parameter. This
> combination means that all job history gets cleaned up rather than just
> the job that has the History Cleanup Task problem raised on Connect as bug
> 322320.
> Chris
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> Under SQL Agent properties/History there are 2 limiting columns for Limit
>> size of job history log.
>> We have Maximum job history set to 12000 and maximum job history rows per
>> job at 150 but we only seem to be able to keep 2 or 3 days worth of
>> jobhistory even though looking in sysjobhistory I can only return 7300
>> rows.
>> I thought that it would keep a maximum of 150 per job to a total of
>> 12000.
>> Is something else limiting the data in sysjobhistory?
>> Thanks
>> Chris
>|||Unfortunately Andrew I have not seen any reposnse to my Connect post.
Thanks
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
> Very interesting Chris. Thanks for the update.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> We found the problem. If you run a maintenance plan that has a History
>> Cleanup Task and its run by an admin level account then the
>> sp_purge_jobhistory does not include a @.job_name parameter. This
>> combination means that all job history gets cleaned up rather than just
>> the job that has the History Cleanup Task problem raised on Connect as
>> bug 322320.
>> Chris
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> Under SQL Agent properties/History there are 2 limiting columns for
>> Limit size of job history log.
>> We have Maximum job history set to 12000 and maximum job history rows
>> per job at 150 but we only seem to be able to keep 2 or 3 days worth of
>> jobhistory even though looking in sysjobhistory I can only return 7300
>> rows.
>> I thought that it would keep a maximum of 150 per job to a total of
>> 12000.
>> Is something else limiting the data in sysjobhistory?
>> Thanks
>> Chris
>>
>|||Actually I just had a look at the sp_purge_jobhistory sp and the bottom line
is that if you don't specify a job ID or name it will delete all history
beyond the date specified. It makes no difference how many rows you have set
in SQL Agent as it does not even check for that. So if you want to keep x
many days worth you need to ensure that the date specified in the Maint Plan
for the history cleanup is far enough out so the history is maintained.
There is no link between the two. The Agent behavior was that way long
before the maint plan had the hist cleanup task and they simply didn't
factor in agents settings when they wrote the task for the maint plans. They
should have have had you specify a minimum # of rows deform they deleted
them by date only.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
> Unfortunately Andrew I have not seen any reposnse to my Connect post.
> Thanks
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>> Very interesting Chris. Thanks for the update.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> We found the problem. If you run a maintenance plan that has a History
>> Cleanup Task and its run by an admin level account then the
>> sp_purge_jobhistory does not include a @.job_name parameter. This
>> combination means that all job history gets cleaned up rather than just
>> the job that has the History Cleanup Task problem raised on Connect as
>> bug 322320.
>> Chris
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> Under SQL Agent properties/History there are 2 limiting columns for
>> Limit size of job history log.
>> We have Maximum job history set to 12000 and maximum job history rows
>> per job at 150 but we only seem to be able to keep 2 or 3 days worth of
>> jobhistory even though looking in sysjobhistory I can only return 7300
>> rows.
>> I thought that it would keep a maximum of 150 per job to a total of
>> 12000.
>> Is something else limiting the data in sysjobhistory?
>> Thanks
>> Chris
>>
>>
>|||Andrew,
That's part of the problem. BOL states that if you are an admin then a
straight sp_purge_jobhistory, without the @.job_name will purge ALL
jobhistory. This is my problem. The maintenance plan does not include the
@.job_name parameter otherwise this might have worked fine. We had to look at
all our jobs that do a cleanup and are run by an admin account to make sure
that we have made the cleanup period long enough.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uW1Q5tdYIHA.5984@.TK2MSFTNGP06.phx.gbl...
> Actually I just had a look at the sp_purge_jobhistory sp and the bottom
> line is that if you don't specify a job ID or name it will delete all
> history beyond the date specified. It makes no difference how many rows
> you have set in SQL Agent as it does not even check for that. So if you
> want to keep x many days worth you need to ensure that the date specified
> in the Maint Plan for the history cleanup is far enough out so the history
> is maintained. There is no link between the two. The Agent behavior was
> that way long before the maint plan had the hist cleanup task and they
> simply didn't factor in agents settings when they wrote the task for the
> maint plans. They should have have had you specify a minimum # of rows
> deform they deleted them by date only.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
>> Unfortunately Andrew I have not seen any reposnse to my Connect post.
>> Thanks
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>> Very interesting Chris. Thanks for the update.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> We found the problem. If you run a maintenance plan that has a History
>> Cleanup Task and its run by an admin level account then the
>> sp_purge_jobhistory does not include a @.job_name parameter. This
>> combination means that all job history gets cleaned up rather than just
>> the job that has the History Cleanup Task problem raised on Connect as
>> bug 322320.
>> Chris
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> Under SQL Agent properties/History there are 2 limiting columns for
>> Limit size of job history log.
>> We have Maximum job history set to 12000 and maximum job history rows
>> per job at 150 but we only seem to be able to keep 2 or 3 days worth
>> of jobhistory even though looking in sysjobhistory I can only return
>> 7300 rows.
>> I thought that it would keep a maximum of 150 per job to a total of
>> 12000.
>> Is something else limiting the data in sysjobhistory?
>> Thanks
>> Chris
>>
>>
>>
>|||Chris,
That only means that you need it to be in the sa or SQLAgentOperatorRole in
order to modify any jobs that are not you own. Since you don't specify a job
ID it has to assume you need to be in one of those two roles. If not it
throws an exception and does nothing. So if you want to keep a certain
amount of history for a particular job I suggest you create your won
scheduled job that calls sp_purge_jobhistory with the proper Job names and
dates for each. You may need to set up a table with any jobs that need a
date other than the default you pass. It's basically do it for every job by
date or one job at a time by date and job id or name. Unfortunately there is
no in between.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:%232tTjgeYIHA.3652@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> That's part of the problem. BOL states that if you are an admin then a
> straight sp_purge_jobhistory, without the @.job_name will purge ALL
> jobhistory. This is my problem. The maintenance plan does not include the
> @.job_name parameter otherwise this might have worked fine. We had to look
> at all our jobs that do a cleanup and are run by an admin account to make
> sure that we have made the cleanup period long enough.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uW1Q5tdYIHA.5984@.TK2MSFTNGP06.phx.gbl...
>> Actually I just had a look at the sp_purge_jobhistory sp and the bottom
>> line is that if you don't specify a job ID or name it will delete all
>> history beyond the date specified. It makes no difference how many rows
>> you have set in SQL Agent as it does not even check for that. So if you
>> want to keep x many days worth you need to ensure that the date specified
>> in the Maint Plan for the history cleanup is far enough out so the
>> history is maintained. There is no link between the two. The Agent
>> behavior was that way long before the maint plan had the hist cleanup
>> task and they simply didn't factor in agents settings when they wrote the
>> task for the maint plans. They should have have had you specify a minimum
>> # of rows deform they deleted them by date only.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
>> Unfortunately Andrew I have not seen any reposnse to my Connect post.
>> Thanks
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>> Very interesting Chris. Thanks for the update.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> We found the problem. If you run a maintenance plan that has a History
>> Cleanup Task and its run by an admin level account then the
>> sp_purge_jobhistory does not include a @.job_name parameter. This
>> combination means that all job history gets cleaned up rather than
>> just the job that has the History Cleanup Task problem raised on
>> Connect as bug 322320.
>> Chris
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> Under SQL Agent properties/History there are 2 limiting columns for
>> Limit size of job history log.
>> We have Maximum job history set to 12000 and maximum job history rows
>> per job at 150 but we only seem to be able to keep 2 or 3 days worth
>> of jobhistory even though looking in sysjobhistory I can only return
>> 7300 rows.
>> I thought that it would keep a maximum of 150 per job to a total of
>> 12000.
>> Is something else limiting the data in sysjobhistory?
>> Thanks
>> Chris
>>
>>
>>
>|||Thanks again Andrew. MS could always fix the bug and include the @.job_name
in the script they produce.
I don't see us changing our backups as you have to be an admin to run the
xp_delete_file that comes from the Maintenance Cleanup Task (See bug 247463
in Connect).
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eJzpwveYIHA.4272@.TK2MSFTNGP05.phx.gbl...
> Chris,
> That only means that you need it to be in the sa or SQLAgentOperatorRole
> in order to modify any jobs that are not you own. Since you don't specify
> a job ID it has to assume you need to be in one of those two roles. If not
> it throws an exception and does nothing. So if you want to keep a certain
> amount of history for a particular job I suggest you create your won
> scheduled job that calls sp_purge_jobhistory with the proper Job names and
> dates for each. You may need to set up a table with any jobs that need a
> date other than the default you pass. It's basically do it for every job
> by date or one job at a time by date and job id or name. Unfortunately
> there is no in between.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:%232tTjgeYIHA.3652@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> That's part of the problem. BOL states that if you are an admin then a
>> straight sp_purge_jobhistory, without the @.job_name will purge ALL
>> jobhistory. This is my problem. The maintenance plan does not include the
>> @.job_name parameter otherwise this might have worked fine. We had to look
>> at all our jobs that do a cleanup and are run by an admin account to make
>> sure that we have made the cleanup period long enough.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:uW1Q5tdYIHA.5984@.TK2MSFTNGP06.phx.gbl...
>> Actually I just had a look at the sp_purge_jobhistory sp and the bottom
>> line is that if you don't specify a job ID or name it will delete all
>> history beyond the date specified. It makes no difference how many rows
>> you have set in SQL Agent as it does not even check for that. So if you
>> want to keep x many days worth you need to ensure that the date
>> specified in the Maint Plan for the history cleanup is far enough out so
>> the history is maintained. There is no link between the two. The Agent
>> behavior was that way long before the maint plan had the hist cleanup
>> task and they simply didn't factor in agents settings when they wrote
>> the task for the maint plans. They should have have had you specify a
>> minimum # of rows deform they deleted them by date only.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
>> Unfortunately Andrew I have not seen any reposnse to my Connect post.
>> Thanks
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>> Very interesting Chris. Thanks for the update.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> We found the problem. If you run a maintenance plan that has a
>> History Cleanup Task and its run by an admin level account then the
>> sp_purge_jobhistory does not include a @.job_name parameter. This
>> combination means that all job history gets cleaned up rather than
>> just the job that has the History Cleanup Task problem raised on
>> Connect as bug 322320.
>> Chris
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>>> Hi,
>>>
>>> Under SQL Agent properties/History there are 2 limiting columns for
>>> Limit size of job history log.
>>> We have Maximum job history set to 12000 and maximum job history
>>> rows per job at 150 but we only seem to be able to keep 2 or 3 days
>>> worth of jobhistory even though looking in sysjobhistory I can only
>>> return 7300 rows.
>>>
>>> I thought that it would keep a maximum of 150 per job to a total of
>>> 12000.
>>>
>>> Is something else limiting the data in sysjobhistory?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>
>>
>>
>>
>|||> Thanks again Andrew. MS could always fix the bug and include the @.job_name
> in the script they produce.
I think you are missing my point. The task in the Maint Plan does not have a
way to specify the job only a date. This isn't a bug it is simply how they
created the task. How do you expect them to specify the job name? Which job
name are they supposed to use? Like I said the task is not in any way shape
or form tied to SQL Agent. It simply deletes rows from MSDB that happen to
be the Agent history. But it knows nothing of the jobs themselves. If it
looped thru each job one by one and specified the name it would still delete
all the rows for each job that were after the date you specified. You end up
with the same result. So this isn't a bug and I am sure they will not fix it
as such. If you want anything other than that behavior you must create it
your self. The Maint Plans are extremely limiting in what they can do and
how they do it. And it is not always clear on what it actually does unless
you trace the plans actions. One of the main reasons why I almost never
recommend using Maint Plans in the first place.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:um0fh8eYIHA.5132@.TK2MSFTNGP02.phx.gbl...
> Thanks again Andrew. MS could always fix the bug and include the @.job_name
> in the script they produce.
> I don't see us changing our backups as you have to be an admin to run the
> xp_delete_file that comes from the Maintenance Cleanup Task (See bug
> 247463 in Connect).
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eJzpwveYIHA.4272@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> That only means that you need it to be in the sa or SQLAgentOperatorRole
>> in order to modify any jobs that are not you own. Since you don't specify
>> a job ID it has to assume you need to be in one of those two roles. If
>> not it throws an exception and does nothing. So if you want to keep a
>> certain amount of history for a particular job I suggest you create your
>> won scheduled job that calls sp_purge_jobhistory with the proper Job
>> names and dates for each. You may need to set up a table with any jobs
>> that need a date other than the default you pass. It's basically do it
>> for every job by date or one job at a time by date and job id or name.
>> Unfortunately there is no in between.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:%232tTjgeYIHA.3652@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> That's part of the problem. BOL states that if you are an admin then a
>> straight sp_purge_jobhistory, without the @.job_name will purge ALL
>> jobhistory. This is my problem. The maintenance plan does not include
>> the @.job_name parameter otherwise this might have worked fine. We had to
>> look at all our jobs that do a cleanup and are run by an admin account
>> to make sure that we have made the cleanup period long enough.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:uW1Q5tdYIHA.5984@.TK2MSFTNGP06.phx.gbl...
>> Actually I just had a look at the sp_purge_jobhistory sp and the bottom
>> line is that if you don't specify a job ID or name it will delete all
>> history beyond the date specified. It makes no difference how many rows
>> you have set in SQL Agent as it does not even check for that. So if
>> you want to keep x many days worth you need to ensure that the date
>> specified in the Maint Plan for the history cleanup is far enough out
>> so the history is maintained. There is no link between the two. The
>> Agent behavior was that way long before the maint plan had the hist
>> cleanup task and they simply didn't factor in agents settings when they
>> wrote the task for the maint plans. They should have have had you
>> specify a minimum # of rows deform they deleted them by date only.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
>> Unfortunately Andrew I have not seen any reposnse to my Connect post.
>> Thanks
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>> Very interesting Chris. Thanks for the update.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>>> Hi,
>>>
>>> We found the problem. If you run a maintenance plan that has a
>>> History Cleanup Task and its run by an admin level account then the
>>> sp_purge_jobhistory does not include a @.job_name parameter. This
>>> combination means that all job history gets cleaned up rather than
>>> just the job that has the History Cleanup Task problem raised on
>>> Connect as bug 322320.
>>>
>>> Chris
>>>
>>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>>> Hi,
>>>
>>> Under SQL Agent properties/History there are 2 limiting columns for
>>> Limit size of job history log.
>>> We have Maximum job history set to 12000 and maximum job history
>>> rows per job at 150 but we only seem to be able to keep 2 or 3 days
>>> worth of jobhistory even though looking in sysjobhistory I can only
>>> return 7300 rows.
>>>
>>> I thought that it would keep a maximum of 150 per job to a total of
>>> 12000.
>>>
>>> Is something else limiting the data in sysjobhistory?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>>
>>>
>>
>>
>>
>|||I see your point Andrew. I hadn't thought about how the Maint Plan would use
the Maintenance Cleanup Task. I am not a Visual Studio user so I don't
always see how the toolset gets used in Management Studio.
It definitely sounds as though taking this task out of the maintenance plans
and creating a nightly job could be the best option.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23I2X1bfYIHA.4172@.TK2MSFTNGP02.phx.gbl...
>> Thanks again Andrew. MS could always fix the bug and include the
>> @.job_name in the script they produce.
> I think you are missing my point. The task in the Maint Plan does not have
> a way to specify the job only a date. This isn't a bug it is simply how
> they created the task. How do you expect them to specify the job name?
> Which job name are they supposed to use? Like I said the task is not in
> any way shape or form tied to SQL Agent. It simply deletes rows from MSDB
> that happen to be the Agent history. But it knows nothing of the jobs
> themselves. If it looped thru each job one by one and specified the name
> it would still delete all the rows for each job that were after the date
> you specified. You end up with the same result. So this isn't a bug and I
> am sure they will not fix it as such. If you want anything other than that
> behavior you must create it your self. The Maint Plans are extremely
> limiting in what they can do and how they do it. And it is not always
> clear on what it actually does unless you trace the plans actions. One of
> the main reasons why I almost never recommend using Maint Plans in the
> first place.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:um0fh8eYIHA.5132@.TK2MSFTNGP02.phx.gbl...
>> Thanks again Andrew. MS could always fix the bug and include the
>> @.job_name in the script they produce.
>> I don't see us changing our backups as you have to be an admin to run the
>> xp_delete_file that comes from the Maintenance Cleanup Task (See bug
>> 247463 in Connect).
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:eJzpwveYIHA.4272@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> That only means that you need it to be in the sa or SQLAgentOperatorRole
>> in order to modify any jobs that are not you own. Since you don't
>> specify a job ID it has to assume you need to be in one of those two
>> roles. If not it throws an exception and does nothing. So if you want to
>> keep a certain amount of history for a particular job I suggest you
>> create your won scheduled job that calls sp_purge_jobhistory with the
>> proper Job names and dates for each. You may need to set up a table with
>> any jobs that need a date other than the default you pass. It's
>> basically do it for every job by date or one job at a time by date and
>> job id or name. Unfortunately there is no in between.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:%232tTjgeYIHA.3652@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> That's part of the problem. BOL states that if you are an admin then a
>> straight sp_purge_jobhistory, without the @.job_name will purge ALL
>> jobhistory. This is my problem. The maintenance plan does not include
>> the @.job_name parameter otherwise this might have worked fine. We had
>> to look at all our jobs that do a cleanup and are run by an admin
>> account to make sure that we have made the cleanup period long enough.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:uW1Q5tdYIHA.5984@.TK2MSFTNGP06.phx.gbl...
>> Actually I just had a look at the sp_purge_jobhistory sp and the
>> bottom line is that if you don't specify a job ID or name it will
>> delete all history beyond the date specified. It makes no difference
>> how many rows you have set in SQL Agent as it does not even check for
>> that. So if you want to keep x many days worth you need to ensure
>> that the date specified in the Maint Plan for the history cleanup is
>> far enough out so the history is maintained. There is no link between
>> the two. The Agent behavior was that way long before the maint plan
>> had the hist cleanup task and they simply didn't factor in agents
>> settings when they wrote the task for the maint plans. They should
>> have have had you specify a minimum # of rows deform they deleted them
>> by date only.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>> news:OoK7jCdYIHA.1208@.TK2MSFTNGP03.phx.gbl...
>> Unfortunately Andrew I have not seen any reposnse to my Connect post.
>> Thanks
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:Or3yu6cYIHA.4808@.TK2MSFTNGP05.phx.gbl...
>>> Very interesting Chris. Thanks for the update.
>>>
>>> --
>>> Andrew J. Kelly SQL MVP
>>> Solid Quality Mentors
>>>
>>>
>>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>>> news:eGw2yxcYIHA.4208@.TK2MSFTNGP04.phx.gbl...
>>> Hi,
>>>
>>> We found the problem. If you run a maintenance plan that has a
>>> History Cleanup Task and its run by an admin level account then the
>>> sp_purge_jobhistory does not include a @.job_name parameter. This
>>> combination means that all job history gets cleaned up rather than
>>> just the job that has the History Cleanup Task problem raised on
>>> Connect as bug 322320.
>>>
>>> Chris
>>>
>>> "Chris Wood" <anonymous@.microsoft.com> wrote in message
>>> news:O9nm5EQPIHA.4272@.TK2MSFTNGP06.phx.gbl...
>>> Hi,
>>>
>>> Under SQL Agent properties/History there are 2 limiting columns
>>> for Limit size of job history log.
>>> We have Maximum job history set to 12000 and maximum job history
>>> rows per job at 150 but we only seem to be able to keep 2 or 3
>>> days worth of jobhistory even though looking in sysjobhistory I
>>> can only return 7300 rows.
>>>
>>> I thought that it would keep a maximum of 150 per job to a total
>>> of 12000.
>>>
>>> Is something else limiting the data in sysjobhistory?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>

Monday, March 12, 2012

Limiting transaction Log file size

Limiting transaction Log file size

Limiting size of a table in SQL server

Friday, March 9, 2012

Limiting log growth during DTS Package

Limiting job history in SQL2005

LIMIT problems

Blog Archive

About Me