Is it possible to write conflict sql in some persistent table.
I know that they a writen in merge replication tables and can be viewed via
conflict viewer
but they a lost after the snapshot run.
I need to keep them forever.
Probably i can write custom resolver who will do thta - but is there any
'out of the box' solution?
Grigoris - as far as I know there isn't any out-of-the-box solution but
perhaps the easiest solution would be to regularly poll the conflict table
and to write the values into an audit table.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Use perfmon to watch the conflicts per second counter of SQL
Server:Replication Merge and run a job which reads the conflict tables when
conflicts occur.
You can also use sp_helpmergearticleconflicts and run it on the publisher
and subscriber. It will return a list of articles with conflicts and you can
then manually or programmatically retrieve them.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Grigoris Tsolakidis" <gcholakidis@.spam_remove.hotmail.com> wrote in message
news:%237acphUZHHA.588@.TK2MSFTNGP06.phx.gbl...
> Is it possible to write conflict sql in some persistent table.
> I know that they a writen in merge replication tables and can be viewed
> via conflict viewer
> but they a lost after the snapshot run.
> I need to keep them forever.
> Probably i can write custom resolver who will do thta - but is there any
> 'out of the box' solution?
>
Showing posts with label log. Show all posts
Showing posts with label log. Show all posts
Wednesday, March 28, 2012
Wednesday, March 21, 2012
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.com
Hi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
..dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defau...v_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.com
Hi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
..dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defau...v_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
--
Message posted via http://www.sqlmonster.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via SQLMonster.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.sqlmonster.comsql
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
--
Message posted via http://www.sqlmonster.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via SQLMonster.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.sqlmonster.comsql
MemToLeave and Thirdy Pary DLLs
Hi
I've been running into problems with a server that indicate that space in th
e
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker thread
s
and using the default -g will add another 256M, bringing the default to 384M
.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defa...ev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
I've been running into problems with a server that indicate that space in th
e
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker thread
s
and using the default -g will add another 256M, bringing the default to 384M
.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defa...ev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com
Memory Warning
I have the following entries in my sql error log:
WARNING: Failed to reserve contiguous memory of Size= 65536.
Buffer Distribution: Stolen=4294940950 Free=112
Procedures=109559
Inram=0 Dirty=1167 Kept=0
I/O=0, Latched=206, Other=123974
Buffer Counts: Commited=208672 Target=208672
Hashed=125347
InternalReservation=346 ExternalReservation=58 Min
Free=128
Procedure Cache: TotalProcs=10484 TotalPages=109559
InUsePages=14527
Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
OS Committed=36671
OS In Use=29121
Query Plan=108697 Optimizer=0
General=3420
Utilities=6 Connection=68
Global Memory Objects: Resource=1808 Locks=77
SQLCache=653 Replication=2
LockBytes=2 ServerGlobal=46
Xact=18
Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
Available=165320
Can anyone help diagnose the problem?
Thanks,
HillaireThere are certain operations that can only happen in a contiguous block of
memory and this is done in what is called the MemToLeave area. By default
you only have about 256MB allocated for this area and you must have run low.
If this repeats you might considering adding the -g parameter to SQL Server
upon startup and reserve more than 256MB. Have a look at "startup options"
in BooksOnLine for more details.
--
Andrew J. Kelly SQL MVP
"kelly" <anonymous@.discussions.microsoft.com> wrote in message
news:08d501c46e65$82f1e660$a601280a@.phx.gbl...
> I have the following entries in my sql error log:
> WARNING: Failed to reserve contiguous memory of Size=> 65536.
> Buffer Distribution: Stolen=4294940950 Free=112
> Procedures=109559
> Inram=0 Dirty=1167 Kept=0
> I/O=0, Latched=206, Other=123974
> Buffer Counts: Commited=208672 Target=208672
> Hashed=125347
> InternalReservation=346 ExternalReservation=58 Min
> Free=128
> Procedure Cache: TotalProcs=10484 TotalPages=109559
> InUsePages=14527
> Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
> OS Committed=36671
> OS In Use=29121
> Query Plan=108697 Optimizer=0
> General=3420
> Utilities=6 Connection=68
> Global Memory Objects: Resource=1808 Locks=77
> SQLCache=653 Replication=2
> LockBytes=2 ServerGlobal=46
> Xact=18
> Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
> Available=165320
> Can anyone help diagnose the problem?
> Thanks,
> Hillaire|||What service pack are on for SQL Server? See if this applies to you:
http://support.microsoft.com/default.aspx?scid=kb;en-us;818095
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"kelly" <anonymous@.discussions.microsoft.com> wrote in message
news:08d501c46e65$82f1e660$a601280a@.phx.gbl...
I have the following entries in my sql error log:
WARNING: Failed to reserve contiguous memory of Size=65536.
Buffer Distribution: Stolen=4294940950 Free=112
Procedures=109559
Inram=0 Dirty=1167 Kept=0
I/O=0, Latched=206, Other=123974
Buffer Counts: Commited=208672 Target=208672
Hashed=125347
InternalReservation=346 ExternalReservation=58 Min
Free=128
Procedure Cache: TotalProcs=10484 TotalPages=109559
InUsePages=14527
Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
OS Committed=36671
OS In Use=29121
Query Plan=108697 Optimizer=0
General=3420
Utilities=6 Connection=68
Global Memory Objects: Resource=1808 Locks=77
SQLCache=653 Replication=2
LockBytes=2 ServerGlobal=46
Xact=18
Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
Available=165320
Can anyone help diagnose the problem?
Thanks,
Hillaire
WARNING: Failed to reserve contiguous memory of Size= 65536.
Buffer Distribution: Stolen=4294940950 Free=112
Procedures=109559
Inram=0 Dirty=1167 Kept=0
I/O=0, Latched=206, Other=123974
Buffer Counts: Commited=208672 Target=208672
Hashed=125347
InternalReservation=346 ExternalReservation=58 Min
Free=128
Procedure Cache: TotalProcs=10484 TotalPages=109559
InUsePages=14527
Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
OS Committed=36671
OS In Use=29121
Query Plan=108697 Optimizer=0
General=3420
Utilities=6 Connection=68
Global Memory Objects: Resource=1808 Locks=77
SQLCache=653 Replication=2
LockBytes=2 ServerGlobal=46
Xact=18
Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
Available=165320
Can anyone help diagnose the problem?
Thanks,
HillaireThere are certain operations that can only happen in a contiguous block of
memory and this is done in what is called the MemToLeave area. By default
you only have about 256MB allocated for this area and you must have run low.
If this repeats you might considering adding the -g parameter to SQL Server
upon startup and reserve more than 256MB. Have a look at "startup options"
in BooksOnLine for more details.
--
Andrew J. Kelly SQL MVP
"kelly" <anonymous@.discussions.microsoft.com> wrote in message
news:08d501c46e65$82f1e660$a601280a@.phx.gbl...
> I have the following entries in my sql error log:
> WARNING: Failed to reserve contiguous memory of Size=> 65536.
> Buffer Distribution: Stolen=4294940950 Free=112
> Procedures=109559
> Inram=0 Dirty=1167 Kept=0
> I/O=0, Latched=206, Other=123974
> Buffer Counts: Commited=208672 Target=208672
> Hashed=125347
> InternalReservation=346 ExternalReservation=58 Min
> Free=128
> Procedure Cache: TotalProcs=10484 TotalPages=109559
> InUsePages=14527
> Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
> OS Committed=36671
> OS In Use=29121
> Query Plan=108697 Optimizer=0
> General=3420
> Utilities=6 Connection=68
> Global Memory Objects: Resource=1808 Locks=77
> SQLCache=653 Replication=2
> LockBytes=2 ServerGlobal=46
> Xact=18
> Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
> Available=165320
> Can anyone help diagnose the problem?
> Thanks,
> Hillaire|||What service pack are on for SQL Server? See if this applies to you:
http://support.microsoft.com/default.aspx?scid=kb;en-us;818095
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"kelly" <anonymous@.discussions.microsoft.com> wrote in message
news:08d501c46e65$82f1e660$a601280a@.phx.gbl...
I have the following entries in my sql error log:
WARNING: Failed to reserve contiguous memory of Size=65536.
Buffer Distribution: Stolen=4294940950 Free=112
Procedures=109559
Inram=0 Dirty=1167 Kept=0
I/O=0, Latched=206, Other=123974
Buffer Counts: Commited=208672 Target=208672
Hashed=125347
InternalReservation=346 ExternalReservation=58 Min
Free=128
Procedure Cache: TotalProcs=10484 TotalPages=109559
InUsePages=14527
Dynamic Memory Manager: Stolen=83213 OS Reserved=40456
OS Committed=36671
OS In Use=29121
Query Plan=108697 Optimizer=0
General=3420
Utilities=6 Connection=68
Global Memory Objects: Resource=1808 Locks=77
SQLCache=653 Replication=2
LockBytes=2 ServerGlobal=46
Xact=18
Query Memory Manager: Grants=1 Waiting=0 Maximum=165378
Available=165320
Can anyone help diagnose the problem?
Thanks,
Hillaire
Wednesday, March 7, 2012
Memory problems
Hi,
I'm seeing some errors in the SQL server error logs:
- -Downgrading backup log buffers from 1024K to 64K -AppDomain 14 (MVXEDU.JBNET\dbryan[runtime].13) is marked for unload due to memory pressure. -Not enough memory was available for trace when trying to run profiler
My server is Win 2003 R2 Enterprise Edition SP1, in Task Manager I see: Physical Memory (k) Total: 33549308 Avail:30361340 System Cache:7235528
I ran some System Monitor counters in two 15 min intervals and get the following:
- Memory: Avail Bytes 3.1050E+010 3.1041E+010 Memory: Pages/Sec 1.592 1.355 Process: Working Set 2639784438 2641416110 SQL Server: Buffer Cache Hit Ratio 99.853 99.846 SQL Server: Buffer Manager Total Pages 194472 194472 SQL Server: Memory Manager Total Server Memory (KB) 1555776 1555776 In the server properties, we do not have AWE enabled and min server memory = 0, max server memory = 2147483647, Index creation Memory = 0 and min memory per query = 1024 (which I think is all the defaults)
I'm new to SQL and Windows so can anyone take a look at my numbers and tell me if they look okay or if anything is giving an inidication of the memory issues I'm having. They look okay to me, but as I said I am new to this so I would love some extra opinions!
Thanks,
Isabelle
What version of SQL Server are you running?
Code Snippet
SELECT @.@.VERSIONAlso run
Code Snippet
xp_msverand post the values from Index 7, 8, 16 and 19
|||What version of SQL Server are you running?
-
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
Oct 14 2005 00:33:37
Copyright (c) 1988-2005 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
xp_msver
7 FileDescription NULL SQL Server Windows NT
8 FileVersion NULL 2005.090.1399.00
16 ProcessorCount 16 16
19 PhysicalMemory 32763 32763 (34354491392)
Thanks!
Isabelle
|||One thing I notice is that you are running the RTM build of SQL Server 2005 (Build 1399), along with SP1 of Windows Server 2003.
If you can, I would really try to get SP2 for SQL Server 2005 installed (Build 3042 or higher), along with SP2 for Windows Server 2003. SP2 for SQL Server 2005 has a lot of fixes related to memory management that may help some.
Since you have 32GB of RAM, you would be much better off running the 64-bit version of Windows Server 2003 along with the 64-bit version of SQL Server 2005. On 32-bit SQL Server 2005, even with AWE enabled, only certain things can use that extra memory above 4GB. Pretty much any CPU made in the last 18-24 months will support 64-bit.
|||You are running the 32bit verion of SQL on a 32bit OS is appears.
You need to enable AWE in order to use more than 2 Gigs of memory. You also need to add the /3GB and /PAE flags to the boot.ini and reboot Windows in order to address over 2 Gigs of Memory per process.
You should limit your memory to 24572 Megs. (Microsoft's new thing is 75% of memory for SQL, 25% for Windows). You can increase that number as needed up to 30715 but no higher than that.
Start there and report back if the issue is still happening.
|||Great! Thanks for the info. I will look into making those changes and see what happens. I am planning on applying the SQL 2005 SP2 to this server this Sunday, so hopefully that will help too.Friday, February 24, 2012
Memory paging out noted in errorlog
As my SQL Server starts, in the SQL error log, there is a message as
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAM
What is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAM
What is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
Memory paging out noted in errorlog
As my SQL Server starts, in the SQL error log, there is a message as
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAMWhat is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAMWhat is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
Memory paging out noted in errorlog
As my SQL Server starts, in the SQL error log, there is a message as
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAMWhat is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
follows:
A significant part of sql server process memory has been paged out. This may
result in a performance degradation. Duration: 0 seconds. Working set (KB):
37376, committed (KB): 105592, memory utilization: 35%.
Do I have to be concerned ? I have 64 bit and 16GB of RAMWhat is min/max server memory settings? Are there other processes running
on the server that are eating up memory? Paging in general is horrible for
performance.
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Hassan" <hassan@.test.com> wrote in message
news:OtgJd4CJIHA.3672@.TK2MSFTNGP02.phx.gbl...
> As my SQL Server starts, in the SQL error log, there is a message as
> follows:
> A significant part of sql server process memory has been paged out. This
> may result in a performance degradation. Duration: 0 seconds. Working set
> (KB): 37376, committed (KB): 105592, memory utilization: 35%.
> Do I have to be concerned ? I have 64 bit and 16GB of RAM
>
Monday, February 20, 2012
Memory Manager
The CPU pegged on a production server this morning. There is a warning
message in the log. I'm not sure what it means. Or what to do to prevent it
in the future.
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
Memory Manager
VM Reserved = 8521512 KB
VM Committed = 8504536 KB
AWE Allocated = 0 KB
Reserved Memory = 1024 KB
Reserved Memory In Use = 0 KB
Then later on
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
MEMORYCLERK_SQLGENERAL (Total)
VM Reserved = 0 KB
VM Committed = 0 KB
AWE Allocated = 0 KB
SM Reserved = 0 KB
SM Committed = 0 KB
SinglePage Allocator = 28920 KB
MultiPage Allocator = 4888 KB
Still later
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
Buffer Counts: Committed=1032192 Target=1047941 Hashed=608946
Internal Reservation=209588 External Reservation=1297
Stolen Potential=571000
Min Free=128 Visible=1047941
Available Paging File=858726400
Finally:
Date 1/23/2008 4:12:19 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source Server
Message
***Stack Dump being sent to D:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\LOG\SQLDump0008.txt
--
Regards,
JamieProbably time to call Microsoft tech support. Or scan the bug fix lists for
all patches you don't have on your server to see if one of them addresses
the symptoms you are seeing.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B2F823A0-5AB3-4EF6-8F16-D515052F7DE4@.microsoft.com...
> The CPU pegged on a production server this morning. There is a warning
> message in the log. I'm not sure what it means. Or what to do to prevent
> it
> in the future.
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> Memory Manager
> VM Reserved = 8521512 KB
> VM Committed = 8504536 KB
> AWE Allocated = 0 KB
> Reserved Memory = 1024 KB
> Reserved Memory In Use = 0 KB
>
> Then later on
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> MEMORYCLERK_SQLGENERAL (Total)
> VM Reserved = 0 KB
> VM Committed = 0 KB
> AWE Allocated = 0 KB
> SM Reserved = 0 KB
> SM Committed = 0 KB
> SinglePage Allocator = 28920 KB
> MultiPage Allocator = 4888 KB
> Still later
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> Buffer Counts: Committed=1032192 Target=1047941 Hashed=608946
> Internal Reservation=209588 External Reservation=1297
> Stolen Potential=571000
> Min Free=128 Visible=1047941
> Available Paging File=858726400
>
> Finally:
> Date 1/23/2008 4:12:19 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source Server
> Message
> ***Stack Dump being sent to D:\Program Files\Microsoft SQL
> Server\MSSQL.1\MSSQL\LOG\SQLDump0008.txt
>
> --
> Regards,
> Jamie
message in the log. I'm not sure what it means. Or what to do to prevent it
in the future.
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
Memory Manager
VM Reserved = 8521512 KB
VM Committed = 8504536 KB
AWE Allocated = 0 KB
Reserved Memory = 1024 KB
Reserved Memory In Use = 0 KB
Then later on
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
MEMORYCLERK_SQLGENERAL (Total)
VM Reserved = 0 KB
VM Committed = 0 KB
AWE Allocated = 0 KB
SM Reserved = 0 KB
SM Committed = 0 KB
SinglePage Allocator = 28920 KB
MultiPage Allocator = 4888 KB
Still later
Date 1/23/2008 4:11:36 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source spid3s
Message
Buffer Counts: Committed=1032192 Target=1047941 Hashed=608946
Internal Reservation=209588 External Reservation=1297
Stolen Potential=571000
Min Free=128 Visible=1047941
Available Paging File=858726400
Finally:
Date 1/23/2008 4:12:19 AM
Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
Source Server
Message
***Stack Dump being sent to D:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\LOG\SQLDump0008.txt
--
Regards,
JamieProbably time to call Microsoft tech support. Or scan the bug fix lists for
all patches you don't have on your server to see if one of them addresses
the symptoms you are seeing.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B2F823A0-5AB3-4EF6-8F16-D515052F7DE4@.microsoft.com...
> The CPU pegged on a production server this morning. There is a warning
> message in the log. I'm not sure what it means. Or what to do to prevent
> it
> in the future.
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> Memory Manager
> VM Reserved = 8521512 KB
> VM Committed = 8504536 KB
> AWE Allocated = 0 KB
> Reserved Memory = 1024 KB
> Reserved Memory In Use = 0 KB
>
> Then later on
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> MEMORYCLERK_SQLGENERAL (Total)
> VM Reserved = 0 KB
> VM Committed = 0 KB
> AWE Allocated = 0 KB
> SM Reserved = 0 KB
> SM Committed = 0 KB
> SinglePage Allocator = 28920 KB
> MultiPage Allocator = 4888 KB
> Still later
> Date 1/23/2008 4:11:36 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source spid3s
> Message
> Buffer Counts: Committed=1032192 Target=1047941 Hashed=608946
> Internal Reservation=209588 External Reservation=1297
> Stolen Potential=571000
> Min Free=128 Visible=1047941
> Available Paging File=858726400
>
> Finally:
> Date 1/23/2008 4:12:19 AM
> Log SQL Server (Archive #1 - 1/23/2008 6:41:00 AM)
> Source Server
> Message
> ***Stack Dump being sent to D:\Program Files\Microsoft SQL
> Server\MSSQL.1\MSSQL\LOG\SQLDump0008.txt
>
> --
> Regards,
> Jamie
Subscribe to:
Posts (Atom)