Showing posts with label cache. Show all posts
Showing posts with label cache. Show all posts

Tuesday, March 27, 2012

Clear Cache via Trigger?

I have a dimension table that gets updated nightly. The dimension table is used by a ROLAP cube.

If you wanted to Clear Cache through the use of a trigger once the dimension table is updated, how would you do it? Is there an easy way to execute the XMLA ClearCache from within T-SQL?

If you have a way to call external process from your procedure, you can use ascmd utility to send any XMLA command to Analysis Server. (http://msdn2.microsoft.com/en-us/ms365187.aspx)

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Clear Cache sqlrs.ReportingServices2005

I'm using the Reporting Service web service to display my reports to the user.
I've deleted some test reports from the server. I've also gone to the
server, searched the test report names, and deleted those.
When I display the available reports using the Reporting Services web
service, the test reports are still there.
How do I remove Reporting Service reports from the server?
Thanks
--
RandyGo to Report Manager, click on report, properties, delete button.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"randy1200" <randy1200@.newsgroups.nospam> wrote in message
news:F873554A-B145-4800-B93F-65B3F6AFC955@.microsoft.com...
> I'm using the Reporting Service web service to display my reports to the
> user.
> I've deleted some test reports from the server. I've also gone to the
> server, searched the test report names, and deleted those.
> When I display the available reports using the Reporting Services web
> service, the test reports are still there.
> How do I remove Reporting Service reports from the server?
> Thanks
> --
> Randy

Sunday, March 25, 2012

clean server cache

Hi,
I am testing .net app. I restored sql server databases with overwrite the
original database.
I re-launch the .net app, I got this error says. Could not connect to the
database DBID = 15...
After I reboot the sql server, I was able to connect again,.
My question is that how do I fix (clean the cache) without rebooting the
server.
thnaks
Hi
I am not sure how this could happen, if you restored the database nothing
should have been connected, and subsequent connections should have connected
ok, providing permissions were in place. Does your .NET application have
connections to other databases? Did you check nothing was connected while you
did the restore?
John
"mecn" wrote:

> Hi,
> I am testing .net app. I restored sql server databases with overwrite the
> original database.
> I re-launch the .net app, I got this error says. Could not connect to the
> database DBID = 15...
> After I reboot the sql server, I was able to connect again,.
> My question is that how do I fix (clean the cache) without rebooting the
> server.
> thnaks
>
>
|||It's very rare, first time for us.
..net application tries to connect dbid = 15 which is the previous db that I
restored with overwrite.
I don't know why the .net application still looking for the old db. not the
db name taht specified in connection string.
After re-boot server(Sql server and iis server in one), everything is ok.
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...[vbcol=seagreen]
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
|||Sorry forgot to mention it. Yes The application is connecting to
multi-databaseses.
Is this the problems?
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...[vbcol=seagreen]
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
|||Hi
I think it could possibly be the cause of the problem, do they remain
connected to the other database while you are restoring? If so try setting
these other databases to single user (and killing the connections) while the
restore is in progress.
John
"mecn" wrote:

> Sorry forgot to mention it. Yes The application is connecting to
> multi-databaseses.
> Is this the problems?
> Thanks
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...
>
>

clean server cache

Hi,
I am testing .net app. I restored sql server databases with overwrite the
original database.
I re-launch the .net app, I got this error says. Could not connect to the
database DBID = 15...
After I reboot the sql server, I was able to connect again,.
My question is that how do I fix (clean the cache) without rebooting the
server.
thnaksHi
I am not sure how this could happen, if you restored the database nothing
should have been connected, and subsequent connections should have connected
ok, providing permissions were in place. Does your .NET application have
connections to other databases? Did you check nothing was connected while yo
u
did the restore?
John
"mecn" wrote:

> Hi,
> I am testing .net app. I restored sql server databases with overwrite the
> original database.
> I re-launch the .net app, I got this error says. Could not connect to the
> database DBID = 15...
> After I reboot the sql server, I was able to connect again,.
> My question is that how do I fix (clean the cache) without rebooting the
> server.
> thnaks
>
>|||It's very rare, first time for us.
.net application tries to connect dbid = 15 which is the previous db that I
restored with overwrite.
I don't know why the .net application still looking for the old db. not the
db name taht specified in connection string.
After re-boot server(Sql server and iis server in one), everything is ok.
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...[vbcol=seagreen]
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
>|||Sorry forgot to mention it. Yes The application is connecting to
multi-databaseses.
Is this the problems?
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...[vbcol=seagreen]
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
>|||Hi
I think it could possibly be the cause of the problem, do they remain
connected to the other database while you are restoring? If so try setting
these other databases to single user (and killing the connections) while the
restore is in progress.
John
"mecn" wrote:

> Sorry forgot to mention it. Yes The application is connecting to
> multi-databaseses.
> Is this the problems?
> Thanks
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...
>
>

clean server cache

Hi,
I am testing .net app. I restored sql server databases with overwrite the
original database.
I re-launch the .net app, I got this error says. Could not connect to the
database DBID = 15...
After I reboot the sql server, I was able to connect again,.
My question is that how do I fix (clean the cache) without rebooting the
server.
thnaksHi
I am not sure how this could happen, if you restored the database nothing
should have been connected, and subsequent connections should have connected
ok, providing permissions were in place. Does your .NET application have
connections to other databases? Did you check nothing was connected while you
did the restore?
John
"mecn" wrote:
> Hi,
> I am testing .net app. I restored sql server databases with overwrite the
> original database.
> I re-launch the .net app, I got this error says. Could not connect to the
> database DBID = 15...
> After I reboot the sql server, I was able to connect again,.
> My question is that how do I fix (clean the cache) without rebooting the
> server.
> thnaks
>
>|||It's very rare, first time for us.
.net application tries to connect dbid = 15 which is the previous db that I
restored with overwrite.
I don't know why the .net application still looking for the old db. not the
db name taht specified in connection string.
After re-boot server(Sql server and iis server in one), everything is ok.
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
>> Hi,
>> I am testing .net app. I restored sql server databases with overwrite the
>> original database.
>> I re-launch the .net app, I got this error says. Could not connect to the
>> database DBID = 15...
>> After I reboot the sql server, I was able to connect again,.
>> My question is that how do I fix (clean the cache) without rebooting the
>> server.
>> thnaks
>>|||Sorry forgot to mention it. Yes The application is connecting to
multi-databaseses.
Is this the problems?
Thanks
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...
> Hi
> I am not sure how this could happen, if you restored the database nothing
> should have been connected, and subsequent connections should have
> connected
> ok, providing permissions were in place. Does your .NET application have
> connections to other databases? Did you check nothing was connected while
> you
> did the restore?
> John
> "mecn" wrote:
>> Hi,
>> I am testing .net app. I restored sql server databases with overwrite the
>> original database.
>> I re-launch the .net app, I got this error says. Could not connect to the
>> database DBID = 15...
>> After I reboot the sql server, I was able to connect again,.
>> My question is that how do I fix (clean the cache) without rebooting the
>> server.
>> thnaks
>>|||Hi
I think it could possibly be the cause of the problem, do they remain
connected to the other database while you are restoring? If so try setting
these other databases to single user (and killing the connections) while the
restore is in progress.
John
"mecn" wrote:
> Sorry forgot to mention it. Yes The application is connecting to
> multi-databaseses.
> Is this the problems?
> Thanks
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:73E30669-7FFD-41BB-BE63-C565B0B083E4@.microsoft.com...
> > Hi
> >
> > I am not sure how this could happen, if you restored the database nothing
> > should have been connected, and subsequent connections should have
> > connected
> > ok, providing permissions were in place. Does your .NET application have
> > connections to other databases? Did you check nothing was connected while
> > you
> > did the restore?
> >
> > John
> >
> > "mecn" wrote:
> >
> >> Hi,
> >> I am testing .net app. I restored sql server databases with overwrite the
> >> original database.
> >> I re-launch the .net app, I got this error says. Could not connect to the
> >> database DBID = 15...
> >>
> >> After I reboot the sql server, I was able to connect again,.
> >>
> >> My question is that how do I fix (clean the cache) without rebooting the
> >> server.
> >>
> >> thnaks
> >>
> >>
> >>
>
>

Wednesday, March 7, 2012

checkpoint process and flushing pages

I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previously,
the cache was only around 800Mb and I could see that alot of data was being
flushed from the cache in order to bring in new data.
Now it has 4Gb but is only using around 1.8Gb (total/target pages).
My question is, during a checkpoint when dirty pages are written to disk,
does it also flush these pages from the cache? I would expect that the
server will use the full 4Gb as best it can and only flush data once the
cache is full but this doesn't seem to be whats happening.
--
Best regards
MarkAdd /3GB in the boot.ini file in the OS root folder, if you have memory
pressure, you should see that counter value (total/target) move up to 2.x GB
range.
Linchi
"Mark Baldwin" wrote:
> I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previously,
> the cache was only around 800Mb and I could see that alot of data was being
> flushed from the cache in order to bring in new data.
> Now it has 4Gb but is only using around 1.8Gb (total/target pages).
> My question is, during a checkpoint when dirty pages are written to disk,
> does it also flush these pages from the cache? I would expect that the
> server will use the full 4Gb as best it can and only flush data once the
> cache is full but this doesn't seem to be whats happening.
> --
> Best regards
> Mark
>
>|||Hello Mark,
I understand that after you upgraded ram from 1GB to 4GB, you still only
see SQL uses 1.8GB. If I'm off-base, please let's know.
Normally, both the SQL Server 2000 Enterprise Edition and SQL Server 2000
Developer Edition can use up to 2 GB of physical memory. With the use of
the AWE enable option, SQL Server can use up to 4 GB of physical memory.
Also, you could enable /3GB switch as Linchi mentioned to let SQL to use
3GB virtual memory for user mode space. Please see the following article
for details:
How to configure SQL Server to use more than 2 GB of physical memory
http://support.microsoft.com/default.aspx?scid=kb;EN-US;274750
Per your question, during a checkpoint when dirty pages are written to
disk, the pages might still be needed and may not flush from the pool. The
checkpoint process goes through the buffer pool, scanning the pages in
buffer number order, and when it finds a dirty page, it looks to see
whether any physically contiguous (on the disk) pages are also dirty so
that it can do a large block write. But this means that it might, for
example, write pages 14, 200, 260, and 1000 at the time that it sees page
14 is dirty. (Those pages might have contiguous physical locations even
though they're far apart in the buffer pool. In this case, the
noncontiguous pages in the buffer pool can be written as a single operation
called a gather-write. I'll define gather-writes in more detail later in
this chapter.) As the process continues to scan the buffer pool, it then
gets to page 1000. Potentially, this page could be dirty again, and it
might be written out a second time. The larger the buffer pool, the greater
the chance that a buffer that's already been written will get dirty again
before the checkpoint is done. To avoid this, each buffer has an associated
bit called a generation number. At the beginning of a checkpoint, all the
bits are toggled to the same value, either all 0's or all 1's. As a
checkpoint checks a page, it toggles the generation bit to the opposite
value. When the checkpoint comes across a page whose bit has already been
toggled, it doesn't write that page. Also, any new pages brought into cache
during the checkpoint get the new generation number, so they won't be
written during that checkpoint cycle. Any pages already written because
they're in proximity to other pages (and are written together in a gather
write) aren't written a second time.
All databases, except for tempdb are checkpointed. Tempdb does not require
recovery (it is recreated every time SQL Server starts) so flushing data
pages to disk is not optimal for tempdb and SQL Server avoids doing so.
Therefore, dirty page may not get to 0 even if checkpoint is run.
You could use DBCC CHECKMEMORYSTATUS to check your SQL Server 2000 memory
status. A dirty page cannot be removed from the SQL Server buffer pool
until the associated log records have been written and the page itself
written to stable media. You can refer to this article:
SQL Server 2000 I/O Basics
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.m
spx
Here is an extraction:
Dirty Page Latency - A page is considered dirty when data modifications
have taken place. A dirty page cannot be removed from the SQL Server buffer
pool until the associated log records have been written and the page itself
written to stable media. Increasing the checkpoint interval (by increasing
the recovery interval) on a busy system moves the pressure of handling
dirty pages to the lazy writer code line. This can result in overall
performance degradation because the lazy writer is not designed to perform
checkpoint-like activities.
The lazy writer does perform proper activity on the dirty pages to ensure
data integrity and free list maintenance but, unlike the checkpoint
process, it is not designed to remove the dirty page I/O latency.
Checkpoints allow dirty pages to be written more aggressively. Leaving the
checkpointing actions to the lazy writer introduces latency because the
lazy writer is forced to perform I/O to age a buffer instead of simple,
in-memory operations to maintain the free list(s). If you have adjusted the
recovery interval, you should watch the lazy writer performance counter(s)
activity closely.
Hope this is helpful. Please feel free to let's know if you have any
questions or comments. Thank you!
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hello Mark,
I'm still interested in this issue. If you have any comments or questions,
please feel free to let's know. I look forward to hearing from you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

checkpoint process and flushing pages

I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previously,
the cache was only around 800Mb and I could see that alot of data was being
flushed from the cache in order to bring in new data.
Now it has 4Gb but is only using around 1.8Gb (total/target pages).
My question is, during a checkpoint when dirty pages are written to disk,
does it also flush these pages from the cache? I would expect that the
server will use the full 4Gb as best it can and only flush data once the
cache is full but this doesn't seem to be whats happening.
Best regards
MarkAdd /3GB in the boot.ini file in the OS root folder, if you have memory
pressure, you should see that counter value (total/target) move up to 2.x GB
range.
Linchi
"Mark Baldwin" wrote:

> I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previousl
y,
> the cache was only around 800Mb and I could see that alot of data was bein
g
> flushed from the cache in order to bring in new data.
> Now it has 4Gb but is only using around 1.8Gb (total/target pages).
> My question is, during a checkpoint when dirty pages are written to disk,
> does it also flush these pages from the cache? I would expect that the
> server will use the full 4Gb as best it can and only flush data once the
> cache is full but this doesn't seem to be whats happening.
> --
> Best regards
> Mark
>
>|||Hello Mark,
I understand that after you upgraded ram from 1GB to 4GB, you still only
see SQL uses 1.8GB. If I'm off-base, please let's know.
Normally, both the SQL Server 2000 Enterprise Edition and SQL Server 2000
Developer Edition can use up to 2 GB of physical memory. With the use of
the AWE enable option, SQL Server can use up to 4 GB of physical memory.
Also, you could enable /3GB switch as Linchi mentioned to let SQL to use
3GB virtual memory for user mode space. Please see the following article
for details:
How to configure SQL Server to use more than 2 GB of physical memory
http://support.microsoft.com/defaul...kb;EN-US;274750
Per your question, during a checkpoint when dirty pages are written to
disk, the pages might still be needed and may not flush from the pool. The
checkpoint process goes through the buffer pool, scanning the pages in
buffer number order, and when it finds a dirty page, it looks to see
whether any physically contiguous (on the disk) pages are also dirty so
that it can do a large block write. But this means that it might, for
example, write pages 14, 200, 260, and 1000 at the time that it sees page
14 is dirty. (Those pages might have contiguous physical locations even
though they're far apart in the buffer pool. In this case, the
noncontiguous pages in the buffer pool can be written as a single operation
called a gather-write. I'll define gather-writes in more detail later in
this chapter.) As the process continues to scan the buffer pool, it then
gets to page 1000. Potentially, this page could be dirty again, and it
might be written out a second time. The larger the buffer pool, the greater
the chance that a buffer that's already been written will get dirty again
before the checkpoint is done. To avoid this, each buffer has an associated
bit called a generation number. At the beginning of a checkpoint, all the
bits are toggled to the same value, either all 0's or all 1's. As a
checkpoint checks a page, it toggles the generation bit to the opposite
value. When the checkpoint comes across a page whose bit has already been
toggled, it doesn't write that page. Also, any new pages brought into cache
during the checkpoint get the new generation number, so they won't be
written during that checkpoint cycle. Any pages already written because
they're in proximity to other pages (and are written together in a gather
write) aren't written a second time.
All databases, except for tempdb are checkpointed. Tempdb does not require
recovery (it is recreated every time SQL Server starts) so flushing data
pages to disk is not optimal for tempdb and SQL Server avoids doing so.
Therefore, dirty page may not get to 0 even if checkpoint is run.
You could use DBCC CHECKMEMORYSTATUS to check your SQL Server 2000 memory
status. A dirty page cannot be removed from the SQL Server buffer pool
until the associated log records have been written and the page itself
written to stable media. You can refer to this article:
SQL Server 2000 I/O Basics
http://www.microsoft.com/technet/pr...n/sqlIObasics.m
spx
Here is an extraction:
Dirty Page Latency - A page is considered dirty when data modifications
have taken place. A dirty page cannot be removed from the SQL Server buffer
pool until the associated log records have been written and the page itself
written to stable media. Increasing the checkpoint interval (by increasing
the recovery interval) on a busy system moves the pressure of handling
dirty pages to the lazy writer code line. This can result in overall
performance degradation because the lazy writer is not designed to perform
checkpoint-like activities.
The lazy writer does perform proper activity on the dirty pages to ensure
data integrity and free list maintenance but, unlike the checkpoint
process, it is not designed to remove the dirty page I/O latency.
Checkpoints allow dirty pages to be written more aggressively. Leaving the
checkpointing actions to the lazy writer introduces latency because the
lazy writer is forced to perform I/O to age a buffer instead of simple,
in-memory operations to maintain the free list(s). If you have adjusted the
recovery interval, you should watch the lazy writer performance counter(s)
activity closely.
Hope this is helpful. Please feel free to let's know if you have any
questions or comments. Thank you!
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
========================================
==========
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications
<http://msdn.microsoft.com/subscript...ps/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscript...rt/default.aspx>.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.

checkpoint process and flushing pages

I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previously,
the cache was only around 800Mb and I could see that alot of data was being
flushed from the cache in order to bring in new data.
Now it has 4Gb but is only using around 1.8Gb (total/target pages).
My question is, during a checkpoint when dirty pages are written to disk,
does it also flush these pages from the cache? I would expect that the
server will use the full 4Gb as best it can and only flush data once the
cache is full but this doesn't seem to be whats happening.
Best regards
Mark
Add /3GB in the boot.ini file in the OS root folder, if you have memory
pressure, you should see that counter value (total/target) move up to 2.x GB
range.
Linchi
"Mark Baldwin" wrote:

> I have a server that has just been upgraded from 1Gb RAM to 4Gb. Previously,
> the cache was only around 800Mb and I could see that alot of data was being
> flushed from the cache in order to bring in new data.
> Now it has 4Gb but is only using around 1.8Gb (total/target pages).
> My question is, during a checkpoint when dirty pages are written to disk,
> does it also flush these pages from the cache? I would expect that the
> server will use the full 4Gb as best it can and only flush data once the
> cache is full but this doesn't seem to be whats happening.
> --
> Best regards
> Mark
>
>
|||Hello Mark,
I understand that after you upgraded ram from 1GB to 4GB, you still only
see SQL uses 1.8GB. If I'm off-base, please let's know.
Normally, both the SQL Server 2000 Enterprise Edition and SQL Server 2000
Developer Edition can use up to 2 GB of physical memory. With the use of
the AWE enable option, SQL Server can use up to 4 GB of physical memory.
Also, you could enable /3GB switch as Linchi mentioned to let SQL to use
3GB virtual memory for user mode space. Please see the following article
for details:
How to configure SQL Server to use more than 2 GB of physical memory
http://support.microsoft.com/default...b;EN-US;274750
Per your question, during a checkpoint when dirty pages are written to
disk, the pages might still be needed and may not flush from the pool. The
checkpoint process goes through the buffer pool, scanning the pages in
buffer number order, and when it finds a dirty page, it looks to see
whether any physically contiguous (on the disk) pages are also dirty so
that it can do a large block write. But this means that it might, for
example, write pages 14, 200, 260, and 1000 at the time that it sees page
14 is dirty. (Those pages might have contiguous physical locations even
though they're far apart in the buffer pool. In this case, the
noncontiguous pages in the buffer pool can be written as a single operation
called a gather-write. I'll define gather-writes in more detail later in
this chapter.) As the process continues to scan the buffer pool, it then
gets to page 1000. Potentially, this page could be dirty again, and it
might be written out a second time. The larger the buffer pool, the greater
the chance that a buffer that's already been written will get dirty again
before the checkpoint is done. To avoid this, each buffer has an associated
bit called a generation number. At the beginning of a checkpoint, all the
bits are toggled to the same value, either all 0's or all 1's. As a
checkpoint checks a page, it toggles the generation bit to the opposite
value. When the checkpoint comes across a page whose bit has already been
toggled, it doesn't write that page. Also, any new pages brought into cache
during the checkpoint get the new generation number, so they won't be
written during that checkpoint cycle. Any pages already written because
they're in proximity to other pages (and are written together in a gather
write) aren't written a second time.
All databases, except for tempdb are checkpointed. Tempdb does not require
recovery (it is recreated every time SQL Server starts) so flushing data
pages to disk is not optimal for tempdb and SQL Server avoids doing so.
Therefore, dirty page may not get to 0 even if checkpoint is run.
You could use DBCC CHECKMEMORYSTATUS to check your SQL Server 2000 memory
status. A dirty page cannot be removed from the SQL Server buffer pool
until the associated log records have been written and the page itself
written to stable media. You can refer to this article:
SQL Server 2000 I/O Basics
http://www.microsoft.com/technet/pro.../sqlIObasics.m
spx
Here is an extraction:
Dirty Page Latency - A page is considered dirty when data modifications
have taken place. A dirty page cannot be removed from the SQL Server buffer
pool until the associated log records have been written and the page itself
written to stable media. Increasing the checkpoint interval (by increasing
the recovery interval) on a busy system moves the pressure of handling
dirty pages to the lazy writer code line. This can result in overall
performance degradation because the lazy writer is not designed to perform
checkpoint-like activities.
The lazy writer does perform proper activity on the dirty pages to ensure
data integrity and free list maintenance but, unlike the checkpoint
process, it is not designed to remove the dirty page I/O latency.
Checkpoints allow dirty pages to be written more aggressively. Leaving the
checkpointing actions to the lazy writer introduces latency because the
lazy writer is forced to perform I/O to age a buffer instead of simple,
in-memory operations to maintain the free list(s). If you have adjusted the
recovery interval, you should watch the lazy writer performance counter(s)
activity closely.
Hope this is helpful. Please feel free to let's know if you have any
questions or comments. Thank you!
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications
<http://msdn.microsoft.com/subscripti...s/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscripti...t/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Saturday, February 25, 2012

CHECKPOINT

wonder if data modified in the buffer data cache
are written to disk in the database file only at the end of the transaction
(commit/rollback) or if portion are written at each checkpoint ?
and next eventually rollback
example:
checkpoint1 checkpoint2 checkpoint3
T1 --!--!--!--commit
does data modified by T1 are partially written to disk at each checkpoint
or only when it is committed ?
In the doc i read
"A SQL Server 2000 checkpoint performs these processes in the current
database:
. Writes to the log file a record marking the start of the checkpoint.
...
Writes to disk all dirty log and data pages."
AT
--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003When you issue a COMMIT, the log buffer is flushed and this guarantees
modified data are permanently persisted. The associated data pages may or
may not have been written to disk at the time of the commit because these
are written asynchronously by worker threads, the lazy writer and the
checkpoint process. A checkpoint writes all dirty pages to disk so, in your
example, any data modified by T1 is written during each of the 3
checkpoints.
If the server were to crash immediately after the commit in your example,
SQL Server would start forward recovery from the log at checkpoint 3 until
the end of the log was reached and them rollback any uncommitted
transactions. The end result is that the data modified by T1 after the last
checkpoint would be in the database and no committed data are lost.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Alan" <t@.t.fr> wrote in message
news:3fe26d7c$0$22334$626a54ce@.news.free.fr...
> wonder if data modified in the buffer data cache
> are written to disk in the database file only at the end of the
transaction
> (commit/rollback) or if portion are written at each checkpoint ?
> and next eventually rollback
> example:
>
> checkpoint1 checkpoint2 checkpoint3
> T1 --!--!--!--commit
>
> does data modified by T1 are partially written to disk at each checkpoint
> or only when it is committed ?
>
> In the doc i read
> "A SQL Server 2000 checkpoint performs these processes in the current
> database:
> . Writes to the log file a record marking the start of the checkpoint.
> ...
> Writes to disk all dirty log and data pages."
>
> AT
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003
>|||Alan
You also posted this in .setup, where I provided an answer, although not
quite as detailed as Dan's.
In the future, please do not post the same question to multiple groups, in
order to only have one thread of responses to follow,
and so people who see your question will know it has been aswered and won't
waste time answering it again.
One comment to Dan... you say that 'any data modified by T1 is written
during EACH of the the 3 checkpoints'. This is not true.
Once the data is written at the first checkpoint, it is no longer dirty, and
will not be written again at subsequent checkpoints. As you say,
only the dirty data is written to disk, but the process of writing to disk
during checkpoint makes that data no longer dirty.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:eypIt4exDHA.4060@.TK2MSFTNGP11.phx.gbl...
> When you issue a COMMIT, the log buffer is flushed and this guarantees
> modified data are permanently persisted. The associated data pages may or
> may not have been written to disk at the time of the commit because these
> are written asynchronously by worker threads, the lazy writer and the
> checkpoint process. A checkpoint writes all dirty pages to disk so, in
your
> example, any data modified by T1 is written during each of the 3
> checkpoints.
> If the server were to crash immediately after the commit in your example,
> SQL Server would start forward recovery from the log at checkpoint 3 until
> the end of the log was reached and them rollback any uncommitted
> transactions. The end result is that the data modified by T1 after the
last
> checkpoint would be in the database and no committed data are lost.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
>
> "Alan" <t@.t.fr> wrote in message
> news:3fe26d7c$0$22334$626a54ce@.news.free.fr...
> > wonder if data modified in the buffer data cache
> > are written to disk in the database file only at the end of the
> transaction
> > (commit/rollback) or if portion are written at each checkpoint ?
> > and next eventually rollback
> >
> > example:
> >
> >
> > checkpoint1 checkpoint2 checkpoint3
> >
> > T1 --!--!--!--commit
> >
> >
> >
> > does data modified by T1 are partially written to disk at each
checkpoint
> > or only when it is committed ?
> >
> >
> > In the doc i read
> > "A SQL Server 2000 checkpoint performs these processes in the current
> > database:
> > . Writes to the log file a record marking the start of the checkpoint.
> > ...
> >
> > Writes to disk all dirty log and data pages."
> >
> >
> >
> > AT
> >
> >
> >
> > --
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003
> >
> >
>|||> Once the data is written at the first checkpoint, it is no longer dirty,
and
> will not be written again at subsequent checkpoints. As you say,
> only the dirty data is written to disk, but the process of writing to disk
> during checkpoint makes that data no longer dirty.
Thanks for the clarification, Kalen. I should have made that point clearer
in my response.
--
Dan Guzman
SQL Server MVP
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:%239BALRfxDHA.2064@.TK2MSFTNGP10.phx.gbl...
> Alan
> You also posted this in .setup, where I provided an answer, although not
> quite as detailed as Dan's.
> In the future, please do not post the same question to multiple groups, in
> order to only have one thread of responses to follow,
> and so people who see your question will know it has been aswered and
won't
> waste time answering it again.
> One comment to Dan... you say that 'any data modified by T1 is written
> during EACH of the the 3 checkpoints'. This is not true.
> Once the data is written at the first checkpoint, it is no longer dirty,
and
> will not be written again at subsequent checkpoints. As you say,
> only the dirty data is written to disk, but the process of writing to disk
> during checkpoint makes that data no longer dirty.
> --
> HTH
> --
> Kalen Delaney
> SQL Server MVP
> www.SolidQualityLearning.com
>
> "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> news:eypIt4exDHA.4060@.TK2MSFTNGP11.phx.gbl...
> > When you issue a COMMIT, the log buffer is flushed and this guarantees
> > modified data are permanently persisted. The associated data pages may
or
> > may not have been written to disk at the time of the commit because
these
> > are written asynchronously by worker threads, the lazy writer and the
> > checkpoint process. A checkpoint writes all dirty pages to disk so, in
> your
> > example, any data modified by T1 is written during each of the 3
> > checkpoints.
> >
> > If the server were to crash immediately after the commit in your
example,
> > SQL Server would start forward recovery from the log at checkpoint 3
until
> > the end of the log was reached and them rollback any uncommitted
> > transactions. The end result is that the data modified by T1 after the
> last
> > checkpoint would be in the database and no committed data are lost.
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> >
> > "Alan" <t@.t.fr> wrote in message
> > news:3fe26d7c$0$22334$626a54ce@.news.free.fr...
> > > wonder if data modified in the buffer data cache
> > > are written to disk in the database file only at the end of the
> > transaction
> > > (commit/rollback) or if portion are written at each checkpoint ?
> > > and next eventually rollback
> > >
> > > example:
> > >
> > >
> > > checkpoint1 checkpoint2 checkpoint3
> > >
> > > T1 --!--!--!--commit
> > >
> > >
> > >
> > > does data modified by T1 are partially written to disk at each
> checkpoint
> > > or only when it is committed ?
> > >
> > >
> > > In the doc i read
> > > "A SQL Server 2000 checkpoint performs these processes in the current
> > > database:
> > > . Writes to the log file a record marking the start of the checkpoint.
> > > ...
> > >
> > > Writes to disk all dirty log and data pages."
> > >
> > >
> > >
> > > AT
> > >
> > >
> > >
> > > --
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003
> > >
> > >
> >
> >
>