It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPD
B
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.
Showing posts with label applying. Show all posts
Showing posts with label applying. Show all posts
Saturday, February 25, 2012
checkpoint on tempdb
It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.
checkpoint on tempdb
It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.
Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.
Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.
Thursday, February 16, 2012
Checking for replication when applying schema changes
All
Is there some simple way to check if a database is being replicated that I
can use in a script? I have 2 copies of a production database, one under
replication and one not, and I would like to have any schema change scripts
check for replication to see which action to take. E.g.
<script>
If <database is replicating>
sp_addreplcolumn ...
Else
Alter Table...
</script>
TIA
Ron Lounsbury
sp_dboption 'pubs','published'
GO
sp_dboption 'pubs','merge publish'
GO
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:uY5tItmUGHA.4764@.TK2MSFTNGP11.phx.gbl...
> All
> Is there some simple way to check if a database is being replicated that I
> can use in a script? I have 2 copies of a production database, one under
> replication and one not, and I would like to have any schema change
> scripts check for replication to see which action to take. E.g.
> <script>
> If <database is replicating>
> sp_addreplcolumn ...
> Else
> Alter Table...
> </script>
> TIA
> Ron Lounsbury
>
|||Hilary
Thanks for the reply. Unfortunately, when I run that against a database
that is participating in replication and one that is not, both give me a
result for the "CurrentSetting" of OFF. This occurs for both "Merge
Publish" and "Publish". Is there something I am missing? I am running SQL
Server 2000, SP 3a (with some hotfixes).
Thanks,
Ron Lounsbury
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:edTAbLnUGHA.4740@.TK2MSFTNGP14.phx.gbl...
> sp_dboption 'pubs','published'
> GO
> sp_dboption 'pubs','merge publish'
> GO
>
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "Ron L" <ronl@.bogus.Address.com> wrote in message
> news:uY5tItmUGHA.4764@.TK2MSFTNGP11.phx.gbl...
>
|||If it returns off it means these databases are not enabled for replication.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:ODmoO2pUGHA.4452@.TK2MSFTNGP12.phx.gbl...
> Hilary
> Thanks for the reply. Unfortunately, when I run that against a database
> that is participating in replication and one that is not, both give me a
> result for the "CurrentSetting" of OFF. This occurs for both "Merge
> Publish" and "Publish". Is there something I am missing? I am running
> SQL Server 2000, SP 3a (with some hotfixes).
> Thanks,
> Ron Lounsbury
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:edTAbLnUGHA.4740@.TK2MSFTNGP14.phx.gbl...
>
|||Hilary
When I run this script in Query Analyzer:
USE NITSS2kDev
exec sp_dboption 'pubs','merge publish'
GO
use NITSS2kdeployed
exec sp_dboption 'pubs','merge publish'
GO
I get these results:
OptionName CurrentSetting
-- --
merge publish off
OptionName CurrentSetting
-- --
merge publish off
NITSS2kDev is actively replicating with 2 other databases, and one of the
replication jobs ran 3 minutes ago. NITSS2kDeployed is not replicating.
The script was run on the Publishing server.
Thanks,
Ron L
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eKM%23DAqUGHA.1444@.TK2MSFTNGP11.phx.gbl...
> If it returns off it means these databases are not enabled for
> replication.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "Ron L" <ronl@.bogus.Address.com> wrote in message
> news:ODmoO2pUGHA.4452@.TK2MSFTNGP12.phx.gbl...
>
|||Oh Man, My Stupid. I don't know where my brain was yesterday. When I put
the right database name in the call it works fine.
Thanks,
Ron L
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:OtXBmGqUGHA.5148@.TK2MSFTNGP12.phx.gbl...
> Hilary
> When I run this script in Query Analyzer:
> USE NITSS2kDev
> exec sp_dboption 'pubs','merge publish'
> GO
> use NITSS2kdeployed
> exec sp_dboption 'pubs','merge publish'
> GO
> I get these results:
> OptionName CurrentSetting
> -- --
> merge publish off
> OptionName CurrentSetting
> -- --
> merge publish off
> NITSS2kDev is actively replicating with 2 other databases, and one of the
> replication jobs ran 3 minutes ago. NITSS2kDeployed is not replicating.
> The script was run on the Publishing server.
> Thanks,
> Ron L
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:eKM%23DAqUGHA.1444@.TK2MSFTNGP11.phx.gbl...
>
Is there some simple way to check if a database is being replicated that I
can use in a script? I have 2 copies of a production database, one under
replication and one not, and I would like to have any schema change scripts
check for replication to see which action to take. E.g.
<script>
If <database is replicating>
sp_addreplcolumn ...
Else
Alter Table...
</script>
TIA
Ron Lounsbury
sp_dboption 'pubs','published'
GO
sp_dboption 'pubs','merge publish'
GO
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:uY5tItmUGHA.4764@.TK2MSFTNGP11.phx.gbl...
> All
> Is there some simple way to check if a database is being replicated that I
> can use in a script? I have 2 copies of a production database, one under
> replication and one not, and I would like to have any schema change
> scripts check for replication to see which action to take. E.g.
> <script>
> If <database is replicating>
> sp_addreplcolumn ...
> Else
> Alter Table...
> </script>
> TIA
> Ron Lounsbury
>
|||Hilary
Thanks for the reply. Unfortunately, when I run that against a database
that is participating in replication and one that is not, both give me a
result for the "CurrentSetting" of OFF. This occurs for both "Merge
Publish" and "Publish". Is there something I am missing? I am running SQL
Server 2000, SP 3a (with some hotfixes).
Thanks,
Ron Lounsbury
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:edTAbLnUGHA.4740@.TK2MSFTNGP14.phx.gbl...
> sp_dboption 'pubs','published'
> GO
> sp_dboption 'pubs','merge publish'
> GO
>
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "Ron L" <ronl@.bogus.Address.com> wrote in message
> news:uY5tItmUGHA.4764@.TK2MSFTNGP11.phx.gbl...
>
|||If it returns off it means these databases are not enabled for replication.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:ODmoO2pUGHA.4452@.TK2MSFTNGP12.phx.gbl...
> Hilary
> Thanks for the reply. Unfortunately, when I run that against a database
> that is participating in replication and one that is not, both give me a
> result for the "CurrentSetting" of OFF. This occurs for both "Merge
> Publish" and "Publish". Is there something I am missing? I am running
> SQL Server 2000, SP 3a (with some hotfixes).
> Thanks,
> Ron Lounsbury
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:edTAbLnUGHA.4740@.TK2MSFTNGP14.phx.gbl...
>
|||Hilary
When I run this script in Query Analyzer:
USE NITSS2kDev
exec sp_dboption 'pubs','merge publish'
GO
use NITSS2kdeployed
exec sp_dboption 'pubs','merge publish'
GO
I get these results:
OptionName CurrentSetting
-- --
merge publish off
OptionName CurrentSetting
-- --
merge publish off
NITSS2kDev is actively replicating with 2 other databases, and one of the
replication jobs ran 3 minutes ago. NITSS2kDeployed is not replicating.
The script was run on the Publishing server.
Thanks,
Ron L
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eKM%23DAqUGHA.1444@.TK2MSFTNGP11.phx.gbl...
> If it returns off it means these databases are not enabled for
> replication.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "Ron L" <ronl@.bogus.Address.com> wrote in message
> news:ODmoO2pUGHA.4452@.TK2MSFTNGP12.phx.gbl...
>
|||Oh Man, My Stupid. I don't know where my brain was yesterday. When I put
the right database name in the call it works fine.
Thanks,
Ron L
"Ron L" <ronl@.bogus.Address.com> wrote in message
news:OtXBmGqUGHA.5148@.TK2MSFTNGP12.phx.gbl...
> Hilary
> When I run this script in Query Analyzer:
> USE NITSS2kDev
> exec sp_dboption 'pubs','merge publish'
> GO
> use NITSS2kdeployed
> exec sp_dboption 'pubs','merge publish'
> GO
> I get these results:
> OptionName CurrentSetting
> -- --
> merge publish off
> OptionName CurrentSetting
> -- --
> merge publish off
> NITSS2kDev is actively replicating with 2 other databases, and one of the
> replication jobs ran 3 minutes ago. NITSS2kDeployed is not replicating.
> The script was run on the Publishing server.
> Thanks,
> Ron L
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:eKM%23DAqUGHA.1444@.TK2MSFTNGP11.phx.gbl...
>
Subscribe to:
Comments (Atom)