When I set up a pull subscription through the wizard, I get the following error when I try to run the distribution agent:
-->
The subscription to publication '(null)' has expired and does not exist. The step failed.
<--
If I set up a push subscription, everything works fine. Any ideas what would cause this issue?
Thanks in advance!
Greg,
there was an issue with this in SQL 7.0:
http://www.kbalertz.com/Feedback_290054.aspx.
Hopefully this is relevant to your case (;-))
Regards,
Paul
|||Here's more info:
I'm using sql server 2000, sp3 on win2kadv server on both publisher and subscriber. It's a Transaction replication publication, no merge or updating back to the publisher. I set up a very simple database with one table that has a primary key and a varchar
(50) column, and 3 rows to isolate the problem. The snapshot runs quick, but the pull distribution agent keeps getting the before mentioned error. If I set up a push subscription, it works.
Any ideas?
|||Greg,
as far as I can tell, this error is raised from
sp_MShelp_distribution_agentid, which is undocumented. The error message
relates to the independant_agent setting when you created the publication.
Please could you run profiler on the subscriber while you try the pull
subscription to check if this is the case. If so please post up the
arguments sent to the procedure and your script which creates the
publication and I'll see if I can get any further.
Regards,
Paul Ibison
|||I figured it out! I set up aliases rather than using ip addresses and it is now working.
http://support.microsoft.com/?id=321822
Showing posts with label pull. Show all posts
Showing posts with label pull. Show all posts
Monday, March 26, 2012
Push vs. Pull Transaction Replication
Q: Push vs. Pull Transactional Replication
We are currently utilizing a push transactional
replication of a subset of the tables in a production
database involving 3 machines; the publisher which is our
production db machine with 4 hyperthreaded processors, 8
GB ram, a distribution db machine with 1 processor, 2 GB
ram, and a subscriber db machine with 2 hyperthreaded
processors, 6 GB ram to which this table subset is
replicated. All machines are SQL EE with SP3. The
subscriber is used for complex searches and has 6 indexed
views resident on it. All replication agents are set to
run continuously.
The Distribution Agent profiles have been left at the
defaults except for QueryTimeout, which has been set to
3600.
Because we cannot simulate this environment for testing,
I would appreciate hearing from anyone who has experience
with a push vs. pull subscription from a performance
standpoint. Thanks very much for your input.
pull offloads the distribution agent to the subscriber. Hence your
performance on your publisher is better.
The problem is that then you no longer have a central point of
administration - in other words you manage your publications and snapshot
agent on your publisher, but your distribution agent on your subscriber.
I can't quantify exactly what performance increase you will have on your
publisher as it is largely a function of load and hardware on your publisher
and subscriber.
You will have to test to see what performance increase you get. You can get
an idea of what it will be by stopping your log reader and distribution
agent on your publisher.
"fundster" <anonymous@.discussions.microsoft.com> wrote in message
news:98dc01c433b2$498477f0$a301280a@.phx.gbl...
> Q: Push vs. Pull Transactional Replication
> We are currently utilizing a push transactional
> replication of a subset of the tables in a production
> database involving 3 machines; the publisher which is our
> production db machine with 4 hyperthreaded processors, 8
> GB ram, a distribution db machine with 1 processor, 2 GB
> ram, and a subscriber db machine with 2 hyperthreaded
> processors, 6 GB ram to which this table subset is
> replicated. All machines are SQL EE with SP3. The
> subscriber is used for complex searches and has 6 indexed
> views resident on it. All replication agents are set to
> run continuously.
> The Distribution Agent profiles have been left at the
> defaults except for QueryTimeout, which has been set to
> 3600.
> Because we cannot simulate this environment for testing,
> I would appreciate hearing from anyone who has experience
> with a push vs. pull subscription from a performance
> standpoint. Thanks very much for your input.
>
|||I would think that you would not need to stop the log reader. Even with a
pull subscription the log reader is still running on the publisher.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||that's a very good point Rand, I missed that.
I was trying to get a baseline "without" replication, but to get a
representative baseline with pull subscriptions you really should have the
log reader agent running.
"Rand Boyd [MSFT]" <rboyd@.onlinemicrosoft.com> wrote in message
news:nxrqWlENEHA.3780@.cpmsftngxa10.phx.gbl...
> I would think that you would not need to stop the log reader. Even with a
> pull subscription the log reader is still running on the publisher.
> Rand
> This posting is provided "as is" with no warranties and confers no rights.
>
sql
We are currently utilizing a push transactional
replication of a subset of the tables in a production
database involving 3 machines; the publisher which is our
production db machine with 4 hyperthreaded processors, 8
GB ram, a distribution db machine with 1 processor, 2 GB
ram, and a subscriber db machine with 2 hyperthreaded
processors, 6 GB ram to which this table subset is
replicated. All machines are SQL EE with SP3. The
subscriber is used for complex searches and has 6 indexed
views resident on it. All replication agents are set to
run continuously.
The Distribution Agent profiles have been left at the
defaults except for QueryTimeout, which has been set to
3600.
Because we cannot simulate this environment for testing,
I would appreciate hearing from anyone who has experience
with a push vs. pull subscription from a performance
standpoint. Thanks very much for your input.
pull offloads the distribution agent to the subscriber. Hence your
performance on your publisher is better.
The problem is that then you no longer have a central point of
administration - in other words you manage your publications and snapshot
agent on your publisher, but your distribution agent on your subscriber.
I can't quantify exactly what performance increase you will have on your
publisher as it is largely a function of load and hardware on your publisher
and subscriber.
You will have to test to see what performance increase you get. You can get
an idea of what it will be by stopping your log reader and distribution
agent on your publisher.
"fundster" <anonymous@.discussions.microsoft.com> wrote in message
news:98dc01c433b2$498477f0$a301280a@.phx.gbl...
> Q: Push vs. Pull Transactional Replication
> We are currently utilizing a push transactional
> replication of a subset of the tables in a production
> database involving 3 machines; the publisher which is our
> production db machine with 4 hyperthreaded processors, 8
> GB ram, a distribution db machine with 1 processor, 2 GB
> ram, and a subscriber db machine with 2 hyperthreaded
> processors, 6 GB ram to which this table subset is
> replicated. All machines are SQL EE with SP3. The
> subscriber is used for complex searches and has 6 indexed
> views resident on it. All replication agents are set to
> run continuously.
> The Distribution Agent profiles have been left at the
> defaults except for QueryTimeout, which has been set to
> 3600.
> Because we cannot simulate this environment for testing,
> I would appreciate hearing from anyone who has experience
> with a push vs. pull subscription from a performance
> standpoint. Thanks very much for your input.
>
|||I would think that you would not need to stop the log reader. Even with a
pull subscription the log reader is still running on the publisher.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||that's a very good point Rand, I missed that.
I was trying to get a baseline "without" replication, but to get a
representative baseline with pull subscriptions you really should have the
log reader agent running.
"Rand Boyd [MSFT]" <rboyd@.onlinemicrosoft.com> wrote in message
news:nxrqWlENEHA.3780@.cpmsftngxa10.phx.gbl...
> I would think that you would not need to stop the log reader. Even with a
> pull subscription the log reader is still running on the publisher.
> Rand
> This posting is provided "as is" with no warranties and confers no rights.
>
sql
Push vs Pull subscriptions
Hello,
I was wondering if there are any rules of thumb in
determining whether or not to use push vs pull
subscriptions?
Any help would be greatly appreciated!
Thanks in advance
Gene,
push will allow control by the publisher, while pull allows the subscriber
to control synchronization, so pull is often used for autonomous users - ie
users who may be disconnected.
It used to be the case that push would use the publisher/distributor's
resources, while pull used the subscriber's resources, but now there's the
posibility of remote agent activation so this distinction is not necessarily
true. However, it is still the case that whose resources are used may be a
consideration.
HTH,
Paul Ibison
|||migrate to pull when you start getting significant locking occuring in your
Distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Gene,
> push will allow control by the publisher, while pull allows the subscriber
> to control synchronization, so pull is often used for autonomous users -
ie
> users who may be disconnected.
> It used to be the case that push would use the publisher/distributor's
> resources, while pull used the subscriber's resources, but now there's the
> posibility of remote agent activation so this distinction is not
necessarily
> true. However, it is still the case that whose resources are used may be a
> consideration.
> HTH,
> Paul Ibison
>
|||Hello
I have configured the PUSH server to be able to push
transactional mode and I cna actually configure the access
list. But when I go to the target server where the updates
are to be pushed to, I do not see the changes.
DO i actually have to create the Dbase first on the target
server?
also, on the target server, when I try to configure the
PULL subscription it is giving me access denied although
on the source/Publisher server, the target server was able
to be defined with no issues.
thanks
>--Original Message--
>migrate to pull when you start getting significant
locking occuring in your[vbcol=seagreen]
>Distribution database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
>news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
allows the subscriber[vbcol=seagreen]
autonomous users -[vbcol=seagreen]
>ie
publisher/distributor's[vbcol=seagreen]
but now there's the[vbcol=seagreen]
distinction is not[vbcol=seagreen]
>necessarily
resources are used may be a
>
>.
>
|||Hello
I have configured the PUSH server to be able to push
transactional mode and I cna actually configure the access
list. But when I go to the target server where the updates
are to be pushed to, I do not see the changes.
DO i actually have to create the Dbase first on the target
server?
also, on the target server, when I try to configure the
PULL subscription it is giving me access denied although
on the source/Publisher server, the target server was able
to be defined with no issues.
thanks
>--Original Message--
>migrate to pull when you start getting significant
locking occuring in your[vbcol=seagreen]
>Distribution database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
>news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
allows the subscriber[vbcol=seagreen]
autonomous users -[vbcol=seagreen]
>ie
publisher/distributor's[vbcol=seagreen]
but now there's the[vbcol=seagreen]
distinction is not[vbcol=seagreen]
>necessarily
resources are used may be a
>
>.
>
|||Yes,
You do need to set up the database on the target server
first. During initial syncronization, replication set up
will ask you if the subsribers have the latest data and
schema. If you say yes, the no snapshot synchronization
will occur, if you say No, a snapshot agent will run and
refresh the data and structure.
Regardless, you do need to have the target DB on the
target server.
>--Original Message--
>Hello
>I have configured the PUSH server to be able to push
>transactional mode and I cna actually configure the
access
>list. But when I go to the target server where the
updates
>are to be pushed to, I do not see the changes.
>DO i actually have to create the Dbase first on the
target
>server?
>also, on the target server, when I try to configure the
>PULL subscription it is giving me access denied although
>on the source/Publisher server, the target server was
able[vbcol=seagreen]
>to be defined with no issues.
>thanks
>
>locking occuring in your
message[vbcol=seagreen]
>allows the subscriber
>autonomous users -
>publisher/distributor's
resources,
>but now there's the
>distinction is not
>resources are used may be a
>.
>
|||Jeff,
when you create the subscription you specify the destination database, and
can create it at this stage, but it isn't created on the fly. During the
subscription set up, you have the choice to initialize or not. If the
destination tables (articles) exist and are identical to teh publishers then
you aren't necessarily required to initialize. Initialization will create a
snapshot of this data which can be BCPd into the destination tables, and
typically create them also. In your case you should reinitialize - force
replication to go through this process again. This will set up the
subscriber so replication can begin.
HTH,
Paul Ibison
I was wondering if there are any rules of thumb in
determining whether or not to use push vs pull
subscriptions?
Any help would be greatly appreciated!
Thanks in advance
Gene,
push will allow control by the publisher, while pull allows the subscriber
to control synchronization, so pull is often used for autonomous users - ie
users who may be disconnected.
It used to be the case that push would use the publisher/distributor's
resources, while pull used the subscriber's resources, but now there's the
posibility of remote agent activation so this distinction is not necessarily
true. However, it is still the case that whose resources are used may be a
consideration.
HTH,
Paul Ibison
|||migrate to pull when you start getting significant locking occuring in your
Distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Gene,
> push will allow control by the publisher, while pull allows the subscriber
> to control synchronization, so pull is often used for autonomous users -
ie
> users who may be disconnected.
> It used to be the case that push would use the publisher/distributor's
> resources, while pull used the subscriber's resources, but now there's the
> posibility of remote agent activation so this distinction is not
necessarily
> true. However, it is still the case that whose resources are used may be a
> consideration.
> HTH,
> Paul Ibison
>
|||Hello
I have configured the PUSH server to be able to push
transactional mode and I cna actually configure the access
list. But when I go to the target server where the updates
are to be pushed to, I do not see the changes.
DO i actually have to create the Dbase first on the target
server?
also, on the target server, when I try to configure the
PULL subscription it is giving me access denied although
on the source/Publisher server, the target server was able
to be defined with no issues.
thanks
>--Original Message--
>migrate to pull when you start getting significant
locking occuring in your[vbcol=seagreen]
>Distribution database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
>news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
allows the subscriber[vbcol=seagreen]
autonomous users -[vbcol=seagreen]
>ie
publisher/distributor's[vbcol=seagreen]
but now there's the[vbcol=seagreen]
distinction is not[vbcol=seagreen]
>necessarily
resources are used may be a
>
>.
>
|||Hello
I have configured the PUSH server to be able to push
transactional mode and I cna actually configure the access
list. But when I go to the target server where the updates
are to be pushed to, I do not see the changes.
DO i actually have to create the Dbase first on the target
server?
also, on the target server, when I try to configure the
PULL subscription it is giving me access denied although
on the source/Publisher server, the target server was able
to be defined with no issues.
thanks
>--Original Message--
>migrate to pull when you start getting significant
locking occuring in your[vbcol=seagreen]
>Distribution database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
>news:uwTxIEeZEHA.3512@.TK2MSFTNGP12.phx.gbl...
allows the subscriber[vbcol=seagreen]
autonomous users -[vbcol=seagreen]
>ie
publisher/distributor's[vbcol=seagreen]
but now there's the[vbcol=seagreen]
distinction is not[vbcol=seagreen]
>necessarily
resources are used may be a
>
>.
>
|||Yes,
You do need to set up the database on the target server
first. During initial syncronization, replication set up
will ask you if the subsribers have the latest data and
schema. If you say yes, the no snapshot synchronization
will occur, if you say No, a snapshot agent will run and
refresh the data and structure.
Regardless, you do need to have the target DB on the
target server.
>--Original Message--
>Hello
>I have configured the PUSH server to be able to push
>transactional mode and I cna actually configure the
access
>list. But when I go to the target server where the
updates
>are to be pushed to, I do not see the changes.
>DO i actually have to create the Dbase first on the
target
>server?
>also, on the target server, when I try to configure the
>PULL subscription it is giving me access denied although
>on the source/Publisher server, the target server was
able[vbcol=seagreen]
>to be defined with no issues.
>thanks
>
>locking occuring in your
message[vbcol=seagreen]
>allows the subscriber
>autonomous users -
>publisher/distributor's
resources,
>but now there's the
>distinction is not
>resources are used may be a
>.
>
|||Jeff,
when you create the subscription you specify the destination database, and
can create it at this stage, but it isn't created on the fly. During the
subscription set up, you have the choice to initialize or not. If the
destination tables (articles) exist and are identical to teh publishers then
you aren't necessarily required to initialize. Initialization will create a
snapshot of this data which can be BCPd into the destination tables, and
typically create them also. In your case you should reinitialize - force
replication to go through this process again. This will set up the
subscriber so replication can begin.
HTH,
Paul Ibison
Push V/S Pull
I believe I have read this before, and apologize for being redundant...
If you have a new server that will be dedicated to reporting, it is more efficient & faster to make this server the Distributor & do a PULL from the production database?
I am pretty sure I have a pretty good understanding of changes being replicated & pushed, but can you help me understand why Pull would be the better option.
Sorry for being thick, I have been reading & reading, and it just isn't sticking...
Thanx!
JLS,
The Distribution Agent can consume significant amounts of memory and CPU cycles, so using pull (or anonymous) subscriptions can increase performance by moving agent processing from the distributor to the subscriber.
The Log Reader Agent writes commands to the distribution database and if you have a remote distributor you also gain by reducing disk I/O on hte production server. Also, the cleanup tasks that are run as a maintenance activity on the distribution database can become expensive and involve significant disk activity.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanx Paul.
I am having an issue of a stored procedure inside a Crystal Report running seamlessly inside my ERP system, faster than my replication records are present in my reporting database.
I am hoping if I change to a PULL subscription with the Distributor being the box where the Reporting database resides, that this problem will be resolved.
I don't want to put a delay into the sp, that would be like shooting myself in the foot. The whole reason for the reporting database is to speed things up on both sides, logically the ERP will run faster once the reports execute on a different box, and this should also be true for the reports, since they will have their own servers.
Any other suggestions for me? I have read everything I can get my hands on.
I'm down to thinking about having 2 separate ODBC drivers, one for the seamless shipping reports that are executing so fast to continue to process on the production db, and all other reports execute on the reporting server & db. But I would really rather have all reports happening on the reporting server & db if at all possible....
"(The ONLY sql server 2000 replication book:" but it's still not available......
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:%23tJzWqdlEHA.3392@.TK2MSFTNGP14.phx.gbl...
JLS,
The Distribution Agent can consume significant amounts of memory and CPU cycles, so using pull (or anonymous) subscriptions can increase performance by moving agent processing from the distributor to the subscriber.
The Log Reader Agent writes commands to the distribution database and if you have a remote distributor you also gain by reducing disk I/O on hte production server. Also, the cleanup tasks that are run as a maintenance activity on the distribution database can become expensive and involve significant disk activity.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||JLS,
I'd definitely recommend this article for performance optimization hints: http://www.microsoft.com/technet/pro.../tranrepl.mspx
In particular, have a look at the sections on the Log Reader Agent Properties and the Distribution Agent Properties.
The most important one in most cases is POLLINGINTERVAL (both agents) in order to reduce the latency to a minimum.
HTH,
Paul Ibison
|||That helps a great deal, Thanx!
One more quick question....
Which table holds the commands to be replicated?
For example, yesterday I had an issue with a duplicate record, and I wanted to clear the command "Call MS_Repl_delete....."
I know I have done this before, but I can't recall what table I cleared it from the last time.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:ObEfrdelEHA.2884@.TK2MSFTNGP09.phx.gbl...
JLS,
I'd definitely recommend this article for performance optimization hints: http://www.microsoft.com/technet/pro.../tranrepl.mspx
In particular, have a look at the sections on the Log Reader Agent Properties and the Distribution Agent Properties.
The most important one in most cases is POLLINGINTERVAL (both agents) in order to reduce the latency to a minimum.
HTH,
Paul Ibison
|||JLS,
select * from distribution.dbo.MSrepl_commands
or
sp_browsereplcmds
Cheers,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
If you have a new server that will be dedicated to reporting, it is more efficient & faster to make this server the Distributor & do a PULL from the production database?
I am pretty sure I have a pretty good understanding of changes being replicated & pushed, but can you help me understand why Pull would be the better option.
Sorry for being thick, I have been reading & reading, and it just isn't sticking...
Thanx!
JLS,
The Distribution Agent can consume significant amounts of memory and CPU cycles, so using pull (or anonymous) subscriptions can increase performance by moving agent processing from the distributor to the subscriber.
The Log Reader Agent writes commands to the distribution database and if you have a remote distributor you also gain by reducing disk I/O on hte production server. Also, the cleanup tasks that are run as a maintenance activity on the distribution database can become expensive and involve significant disk activity.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanx Paul.
I am having an issue of a stored procedure inside a Crystal Report running seamlessly inside my ERP system, faster than my replication records are present in my reporting database.
I am hoping if I change to a PULL subscription with the Distributor being the box where the Reporting database resides, that this problem will be resolved.
I don't want to put a delay into the sp, that would be like shooting myself in the foot. The whole reason for the reporting database is to speed things up on both sides, logically the ERP will run faster once the reports execute on a different box, and this should also be true for the reports, since they will have their own servers.
Any other suggestions for me? I have read everything I can get my hands on.
I'm down to thinking about having 2 separate ODBC drivers, one for the seamless shipping reports that are executing so fast to continue to process on the production db, and all other reports execute on the reporting server & db. But I would really rather have all reports happening on the reporting server & db if at all possible....
"(The ONLY sql server 2000 replication book:" but it's still not available......
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:%23tJzWqdlEHA.3392@.TK2MSFTNGP14.phx.gbl...
JLS,
The Distribution Agent can consume significant amounts of memory and CPU cycles, so using pull (or anonymous) subscriptions can increase performance by moving agent processing from the distributor to the subscriber.
The Log Reader Agent writes commands to the distribution database and if you have a remote distributor you also gain by reducing disk I/O on hte production server. Also, the cleanup tasks that are run as a maintenance activity on the distribution database can become expensive and involve significant disk activity.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||JLS,
I'd definitely recommend this article for performance optimization hints: http://www.microsoft.com/technet/pro.../tranrepl.mspx
In particular, have a look at the sections on the Log Reader Agent Properties and the Distribution Agent Properties.
The most important one in most cases is POLLINGINTERVAL (both agents) in order to reduce the latency to a minimum.
HTH,
Paul Ibison
|||That helps a great deal, Thanx!
One more quick question....
Which table holds the commands to be replicated?
For example, yesterday I had an issue with a duplicate record, and I wanted to clear the command "Call MS_Repl_delete....."
I know I have done this before, but I can't recall what table I cleared it from the last time.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:ObEfrdelEHA.2884@.TK2MSFTNGP09.phx.gbl...
JLS,
I'd definitely recommend this article for performance optimization hints: http://www.microsoft.com/technet/pro.../tranrepl.mspx
In particular, have a look at the sections on the Log Reader Agent Properties and the Distribution Agent Properties.
The most important one in most cases is POLLINGINTERVAL (both agents) in order to reduce the latency to a minimum.
HTH,
Paul Ibison
|||JLS,
select * from distribution.dbo.MSrepl_commands
or
sp_browsereplcmds
Cheers,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
push table only on handheld database
I'm able to pull down all my tables needed, but I need to push a table from my handheld database that was not pulled. Is this possible?
The table is used to save data on some input screen on my handheld application and I need to push it to a 'staging' table on my main sql server before it is inserted into the correct tables.
Is there a way to do this?
Why not use RDA.SubmitSQL("INSERT INTO xxx ....) ?|||SubmitSQL("insert xxx") will work?
So the insert statement will be the insertion of the table on my main SQL Server? I've been under the impression that you can't push a table unless you pull it first? Is that not true?
So here is what I have.
on my handeld database
table1 - pulled
table2 - not pulled
main SQL Server database
table1
table2 - 'staged table'
since table2 wasn't not pulled and is used as a data collection table on the handheld, I can do SubmitSQL("insert into table2 (xxx)") and that will work?
|||Yes, SubmitSQL simply executes SQL statements on the database server, any you can code whatever SQL statements you like.
push table only on handheld database
I'm able to pull down all my tables needed, but I need to push a table from my handheld database that was not pulled. Is this possible?
The table is used to save data on some input screen on my handheld application and I need to push it to a 'staging' table on my main sql server before it is inserted into the correct tables.
Is there a way to do this?
Why not use RDA.SubmitSQL("INSERT INTO xxx ....) ?|||SubmitSQL("insert xxx") will work?
So the insert statement will be the insertion of the table on my main SQL Server? I've been under the impression that you can't push a table unless you pull it first? Is that not true?
So here is what I have.
on my handeld database
table1 - pulled
table2 - not pulled
main SQL Server database
table1
table2 - 'staged table'
since table2 wasn't not pulled and is used as a data collection table on the handheld, I can do SubmitSQL("insert into table2 (xxx)") and that will work?
|||Yes, SubmitSQL simply executes SQL statements on the database server, any you can code whatever SQL statements you like.sql
Push replication
I need to pull the schema only with no data, then push the data back without
deletes on the publisher, then delete the client data. Next time these
deletes would not be pushed up. Only new data.
SQL Server 2005 June CTP and SQL Mobile 2005
"msmith" wrote:
> I need to pull the schema only with no data, then push the data back without
> deletes on the publisher, then delete the client data. Next time these
> deletes would not be pushed up. Only new data.
deletes on the publisher, then delete the client data. Next time these
deletes would not be pushed up. Only new data.
SQL Server 2005 June CTP and SQL Mobile 2005
"msmith" wrote:
> I need to pull the schema only with no data, then push the data back without
> deletes on the publisher, then delete the client data. Next time these
> deletes would not be pushed up. Only new data.
push or pull, local or remote
sql2k sp3
Transactial, 1 way replication to 1 Subscriber. I want to offload as much
processing to the Subscriber as possible. I was thinking to use a Remote
Distributor (Subscriber) with Push Subscriptions would be good. (Push for
Security/ Firewall reasons.) Is this correct thinking?
TIA, ChrisR
I normally only migrate to a remote distributor when circumstances warrant.
For instance when my publisher is under load and I start to experience
locking especially in the distribution database.
There is an added point of failure if you move to a remote distributor when
you don't really need to.
Pull is best when you have large numbers of subscribers. You do lose the
central point of administration.
You might want to think about remote activation. This will offload your
agent processing to your subscriber. Its like a push subscription but with
less overhead on the publisher, and more on the subscriber.
For firewall issues you would use pull with FTP. Push doesn't work welll
over a firewall.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
> sql2k sp3
> Transactial, 1 way replication to 1 Subscriber. I want to offload as much
> processing to the Subscriber as possible. I was thinking to use a Remote
> Distributor (Subscriber) with Push Subscriptions would be good. (Push for
> Security/ Firewall reasons.) Is this correct thinking?
> TIA, ChrisR
>
|||> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
I had always thought this is what a Remote Distributor would do? Is this
incorrect? Also, Push/ Pull doesnt have anything to do with where the load
is placed, right?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> I normally only migrate to a remote distributor when circumstances
warrant.
> For instance when my publisher is under load and I start to experience
> locking especially in the distribution database.
> There is an added point of failure if you move to a remote distributor
when[vbcol=seagreen]
> you don't really need to.
> Pull is best when you have large numbers of subscribers. You do lose the
> central point of administration.
> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
> For firewall issues you would use pull with FTP. Push doesn't work welll
> over a firewall.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
much[vbcol=seagreen]
for
>
|||No, a remote distributor contains all the commands to be replicated and the
history if you are using a push subscription.
If you are using a pull subscription your remote distributor only contains
all the commands to be replicated. This history is on the subscriber. If
your remote distributor is on your subscriber, and your pull subscription
agents are there as well then the commands and history are there.
With remote activiation your agent exe will run wherever you specify -
publisher, subcsriber or distributor. So you can run a pull subscription and
have the agent run on your publisher or a push subscription and have your
agent run on your publisher.
HTH
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
with[vbcol=seagreen]
>
> I had always thought this is what a Remote Distributor would do? Is this
> incorrect? Also, Push/ Pull doesnt have anything to do with where the load
> is placed, right?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> warrant.
> when
with[vbcol=seagreen]
> much
Remote
> for
>
|||So then whats the benifit to having a remote distributor. I always thought
if processing got really heavy on the Publisher I could just use a Remote
Distributor and that would fix it. It sounds like my whole thought process
is off?
My goals are:
To offload all the processing to the Subscriber. Keep as secure as possible.
After reading all this it sounds like I should:
Use a Local Distributor. Use Remote Activation Agent. Use Pull Subscriptions
with FTP.
Is this how you would do it for my scenario?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> No, a remote distributor contains all the commands to be replicated and
the
> history if you are using a push subscription.
> If you are using a pull subscription your remote distributor only contains
> all the commands to be replicated. This history is on the subscriber. If
> your remote distributor is on your subscriber, and your pull subscription
> agents are there as well then the commands and history are there.
> With remote activiation your agent exe will run wherever you specify -
> publisher, subcsriber or distributor. So you can run a pull subscription
and[vbcol=seagreen]
> have the agent run on your publisher or a push subscription and have your
> agent run on your publisher.
> HTH
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...
your[vbcol=seagreen]
> with
load[vbcol=seagreen]
the[vbcol=seagreen]
your[vbcol=seagreen]
> with
welll[vbcol=seagreen]
> Remote
(Push
>
|||You are completely correct. To offload some of the processing involved in
replication use a remote distributor. The only replication overhead on the
publisher will be the log reader agent which will still run on the
publisher.
However, you will then have another point of failure. Life is simpler with a
local distributor.
When you migrate to pull you get better performance as the distribution
agent runs on the subscriber. But then you have to administer your
distribution agent on your subscriber, and consequently lose your single
central point of administration.
So its a trade off, administrative simplicity vs. the performance boost.
Same with remote activation; it is slightly more complex, but there can be
performance benefits by running your push agent on your subscriber - note
that is push agent, not pull. If the server you are running your
distribution agent on (publisher, subscriber, distributor) is under load you
may get dcom timeouts when you agent starts up.
If you chose the local distributor, and pull subscriptions with FTP you are
probably getting better performance than with local and push. You would get
better performance with remote and pull, but then there is the added
administrative burden - albeit slight.
If you want to throw remote activation into the mix where is your agent
going to run? Publisher, subscriber, distributor? For performance reasons
it should be the distributor or subscriber. If its the subscriber you should
be using a simple pull.
"ChrisR" <chris@.noemail.com> wrote in message
news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
> So then whats the benifit to having a remote distributor. I always thought
> if processing got really heavy on the Publisher I could just use a Remote
> Distributor and that would fix it. It sounds like my whole thought process
> is off?
> My goals are:
> To offload all the processing to the Subscriber. Keep as secure as
> possible.
> After reading all this it sounds like I should:
> Use a Local Distributor. Use Remote Activation Agent. Use Pull
> Subscriptions
> with FTP.
> Is this how you would do it for my scenario?
>
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> the
> and
> your
> load
> the
> your
> welll
> (Push
>
|||How would you do it? Publisher performance is more important to me than
centralized administration. It sounds like the ultimate performance boost
would be:
Remote Distributor. Pull Subscriptions. Remote Agent.
Would you agree?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>
|||I did some testing a couple of years ago with pulling from an FTP site.
Doesnt it have an issue with filling up the C: drive? Something like making
a copy of the snapshot in a temp folder?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>
Transactial, 1 way replication to 1 Subscriber. I want to offload as much
processing to the Subscriber as possible. I was thinking to use a Remote
Distributor (Subscriber) with Push Subscriptions would be good. (Push for
Security/ Firewall reasons.) Is this correct thinking?
TIA, ChrisR
I normally only migrate to a remote distributor when circumstances warrant.
For instance when my publisher is under load and I start to experience
locking especially in the distribution database.
There is an added point of failure if you move to a remote distributor when
you don't really need to.
Pull is best when you have large numbers of subscribers. You do lose the
central point of administration.
You might want to think about remote activation. This will offload your
agent processing to your subscriber. Its like a push subscription but with
less overhead on the publisher, and more on the subscriber.
For firewall issues you would use pull with FTP. Push doesn't work welll
over a firewall.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
> sql2k sp3
> Transactial, 1 way replication to 1 Subscriber. I want to offload as much
> processing to the Subscriber as possible. I was thinking to use a Remote
> Distributor (Subscriber) with Push Subscriptions would be good. (Push for
> Security/ Firewall reasons.) Is this correct thinking?
> TIA, ChrisR
>
|||> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
I had always thought this is what a Remote Distributor would do? Is this
incorrect? Also, Push/ Pull doesnt have anything to do with where the load
is placed, right?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> I normally only migrate to a remote distributor when circumstances
warrant.
> For instance when my publisher is under load and I start to experience
> locking especially in the distribution database.
> There is an added point of failure if you move to a remote distributor
when[vbcol=seagreen]
> you don't really need to.
> Pull is best when you have large numbers of subscribers. You do lose the
> central point of administration.
> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
> For firewall issues you would use pull with FTP. Push doesn't work welll
> over a firewall.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
much[vbcol=seagreen]
for
>
|||No, a remote distributor contains all the commands to be replicated and the
history if you are using a push subscription.
If you are using a pull subscription your remote distributor only contains
all the commands to be replicated. This history is on the subscriber. If
your remote distributor is on your subscriber, and your pull subscription
agents are there as well then the commands and history are there.
With remote activiation your agent exe will run wherever you specify -
publisher, subcsriber or distributor. So you can run a pull subscription and
have the agent run on your publisher or a push subscription and have your
agent run on your publisher.
HTH
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
with[vbcol=seagreen]
>
> I had always thought this is what a Remote Distributor would do? Is this
> incorrect? Also, Push/ Pull doesnt have anything to do with where the load
> is placed, right?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> warrant.
> when
with[vbcol=seagreen]
> much
Remote
> for
>
|||So then whats the benifit to having a remote distributor. I always thought
if processing got really heavy on the Publisher I could just use a Remote
Distributor and that would fix it. It sounds like my whole thought process
is off?
My goals are:
To offload all the processing to the Subscriber. Keep as secure as possible.
After reading all this it sounds like I should:
Use a Local Distributor. Use Remote Activation Agent. Use Pull Subscriptions
with FTP.
Is this how you would do it for my scenario?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> No, a remote distributor contains all the commands to be replicated and
the
> history if you are using a push subscription.
> If you are using a pull subscription your remote distributor only contains
> all the commands to be replicated. This history is on the subscriber. If
> your remote distributor is on your subscriber, and your pull subscription
> agents are there as well then the commands and history are there.
> With remote activiation your agent exe will run wherever you specify -
> publisher, subcsriber or distributor. So you can run a pull subscription
and[vbcol=seagreen]
> have the agent run on your publisher or a push subscription and have your
> agent run on your publisher.
> HTH
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...
your[vbcol=seagreen]
> with
load[vbcol=seagreen]
the[vbcol=seagreen]
your[vbcol=seagreen]
> with
welll[vbcol=seagreen]
> Remote
(Push
>
|||You are completely correct. To offload some of the processing involved in
replication use a remote distributor. The only replication overhead on the
publisher will be the log reader agent which will still run on the
publisher.
However, you will then have another point of failure. Life is simpler with a
local distributor.
When you migrate to pull you get better performance as the distribution
agent runs on the subscriber. But then you have to administer your
distribution agent on your subscriber, and consequently lose your single
central point of administration.
So its a trade off, administrative simplicity vs. the performance boost.
Same with remote activation; it is slightly more complex, but there can be
performance benefits by running your push agent on your subscriber - note
that is push agent, not pull. If the server you are running your
distribution agent on (publisher, subscriber, distributor) is under load you
may get dcom timeouts when you agent starts up.
If you chose the local distributor, and pull subscriptions with FTP you are
probably getting better performance than with local and push. You would get
better performance with remote and pull, but then there is the added
administrative burden - albeit slight.
If you want to throw remote activation into the mix where is your agent
going to run? Publisher, subscriber, distributor? For performance reasons
it should be the distributor or subscriber. If its the subscriber you should
be using a simple pull.
"ChrisR" <chris@.noemail.com> wrote in message
news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
> So then whats the benifit to having a remote distributor. I always thought
> if processing got really heavy on the Publisher I could just use a Remote
> Distributor and that would fix it. It sounds like my whole thought process
> is off?
> My goals are:
> To offload all the processing to the Subscriber. Keep as secure as
> possible.
> After reading all this it sounds like I should:
> Use a Local Distributor. Use Remote Activation Agent. Use Pull
> Subscriptions
> with FTP.
> Is this how you would do it for my scenario?
>
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> the
> and
> your
> load
> the
> your
> welll
> (Push
>
|||How would you do it? Publisher performance is more important to me than
centralized administration. It sounds like the ultimate performance boost
would be:
Remote Distributor. Pull Subscriptions. Remote Agent.
Would you agree?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>
|||I did some testing a couple of years ago with pulling from an FTP site.
Doesnt it have an issue with filling up the C: drive? Something like making
a copy of the snapshot in a temp folder?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>
Push or Pull replication
What is better to use, Push or Pull Replication? What are the advantages and disadvantages?
It really depends on your environment.
Check out this article,
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/tranrepl.mspx
Here is some advantage using pull subscription:
Using Pull Subscriptions
The Distribution Agent runs on the Distributor for push subscriptions and on Subscribers for pull or anonymous subscriptions. Using pull or anonymous subscriptions can increase performance by moving Distribution Agent processing from the Distributor to Subscribers.
Anonymous subscriptions, which are especially useful for Internet applications, do not require information about the Subscriber to be stored in the distribution database at the Distributor for transactional replication. Not having to maintain information on Subscribers using anonymous subscriptions reduces the resource demands on the Publisher and Distributor.
Anonymous subscriptions are a special category of pull subscriptions. In regular pull subscriptions, the Distribution Agent runs at the Subscriber (thereby reducing the resource demands on the Distributor), but it still stores information at the Publisher.
However, since pull subscription is managed on the subscriber, so if you have many subscribers with different sync schedule, there maybe more administrative overhead.
Gary
sqlPush or Pull for Replication-Based failover
I am trying to devise a setup where I can use Replication to maintain a
failover server in case of a critical failure on the primary DB server. I
plan on using transactional replication and immeadiate updating for minimal
latency, but I have a couple of questions about the right setup:
1. Push or pull? Push would allow for 2 phase commit, which seems
desirable. On the other hand, when system 1 fails, don't you need to "break
the link" between the subscriber and publisher (i.e. run sp_dropsubscription)
in order to ensure proper operation?
2. We have some identity columns. I am planning on marking them as NOT FOR
REPLICATION and then in a failover scenario, run DBCC CHECKIDENT('my
table',RESEED,<looked up max from table>) to reseed the identity on the
secondary. Is this an advisable strategy?
I have been looking at other solutions in this area which involve modifying
some of the generated procs and I would like to avoid that so that we can use
as much out of the box as possible (trying not to pretend I can engineer
better than MS
).
Thanks,
Tom
Push or pull doesn't really relate to 2PC - the setting really controls who
initiates the distributor->subscriber traffic. If the subscriber fails, the
2PC won't matter because it is in the direction subscriber->distributor. The
other way round and you'll have to remove the subscription.
For the identities, the easiest solution is to set up immediateupdating with
queued updating failover and have a large seed set up.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Could you clarify a bit? does subscriber->distributor imply pull whereas
distributor ->subscriber implies push? I am trying to understand when I
would have to remove the subscription.
Thanks,
Tom
"Paul Ibison" wrote:
> Push or pull doesn't really relate to 2PC - the setting really controls who
> initiates the distributor->subscriber traffic. If the subscriber fails, the
> 2PC won't matter because it is in the direction subscriber->distributor. The
> other way round and you'll have to remove the subscription.
> For the identities, the easiest solution is to set up immediateupdating with
> queued updating failover and have a large seed set up.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||The directions I indicated refer to data flow, eg subscriber->distributor in
your case is 2PC, whereas distributor ->subscriber is the PUSH/PULL running
of the distribution agent. I think you're mixing PUSH/PULL with the flow of
data, while the 2 are not really related in that way - it's more which
computer is going to do the synchronization work.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
failover server in case of a critical failure on the primary DB server. I
plan on using transactional replication and immeadiate updating for minimal
latency, but I have a couple of questions about the right setup:
1. Push or pull? Push would allow for 2 phase commit, which seems
desirable. On the other hand, when system 1 fails, don't you need to "break
the link" between the subscriber and publisher (i.e. run sp_dropsubscription)
in order to ensure proper operation?
2. We have some identity columns. I am planning on marking them as NOT FOR
REPLICATION and then in a failover scenario, run DBCC CHECKIDENT('my
table',RESEED,<looked up max from table>) to reseed the identity on the
secondary. Is this an advisable strategy?
I have been looking at other solutions in this area which involve modifying
some of the generated procs and I would like to avoid that so that we can use
as much out of the box as possible (trying not to pretend I can engineer
better than MS
).Thanks,
Tom
Push or pull doesn't really relate to 2PC - the setting really controls who
initiates the distributor->subscriber traffic. If the subscriber fails, the
2PC won't matter because it is in the direction subscriber->distributor. The
other way round and you'll have to remove the subscription.
For the identities, the easiest solution is to set up immediateupdating with
queued updating failover and have a large seed set up.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Could you clarify a bit? does subscriber->distributor imply pull whereas
distributor ->subscriber implies push? I am trying to understand when I
would have to remove the subscription.
Thanks,
Tom
"Paul Ibison" wrote:
> Push or pull doesn't really relate to 2PC - the setting really controls who
> initiates the distributor->subscriber traffic. If the subscriber fails, the
> 2PC won't matter because it is in the direction subscriber->distributor. The
> other way round and you'll have to remove the subscription.
> For the identities, the easiest solution is to set up immediateupdating with
> queued updating failover and have a large seed set up.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||The directions I indicated refer to data flow, eg subscriber->distributor in
your case is 2PC, whereas distributor ->subscriber is the PUSH/PULL running
of the distribution agent. I think you're mixing PUSH/PULL with the flow of
data, while the 2 are not really related in that way - it's more which
computer is going to do the synchronization work.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Push or Pull
I've always had a hard time getting my head around Push and Pull
Subscriptions.
Ive read that it really doesnt have a huge impact on a box, and that what
really matters is where the Distributor is. That Push or Pull is more for
Administrative type of stuff. Just not sure about this.
I just started at a company that uses quite a bit of replication. So far Ive
come up with two Publishers and propably or 6 or 8 Subscribers. The
Distributors are both Local and the Subscriptions are all Pull. It is all
Transactional Replication, some of it continuos, some every 15 minutes.
So my questions are:
Would I be better off to use a dedicated Remote Distributor? One of my main
objectives here is to speed up these boxes.
If I did use a Remote Distributor, would it matter if I went to Push
Subscriptions for centralized Administration? Or would that defeat my goal
of speeding up the Publisher?
I don't like remote distributors and hesitate before using them. If your
remote distributor goes down you can end up with ballooning tlogs on your
publication databases and you can have problems getting your log reader
agent working again.
If you have high throughput and are experiencing locking you might want to
look at them.
Pull subscriptions do lessen the load on the publisher. They are the best
solution when you have a lot of subscribers, are replicating across the
internet or when your subscribers are not well connected or not always
connected, you can live with no central point of administration (other than
replication monitor group).
the rest of the answers are inline.
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
"ChrisR" <noemail@.bla.com> wrote in message
news:%23ydW$eHNFHA.3668@.TK2MSFTNGP14.phx.gbl...
> I've always had a hard time getting my head around Push and Pull
> Subscriptions.
> Ive read that it really doesnt have a huge impact on a box, and that what
> really matters is where the Distributor is. That Push or Pull is more for
> Administrative type of stuff. Just not sure about this.
> I just started at a company that uses quite a bit of replication. So far
Ive
> come up with two Publishers and propably or 6 or 8 Subscribers. The
> Distributors are both Local and the Subscriptions are all Pull. It is all
> Transactional Replication, some of it continuos, some every 15 minutes.
> So my questions are:
> Would I be better off to use a dedicated Remote Distributor? One of my
main
> objectives here is to speed up these boxes.
I would only use this if you are experiencing considerable locking in your
distribution database.
> If I did use a Remote Distributor, would it matter if I went to Push
> Subscriptions for centralized Administration?
No, not for a few always connected subscribers.
Or would that defeat my goal
> of speeding up the Publisher?
Stop your log reader and distribution agent. Do you get a significant
increase in performance. If so, migrate; if not (and suspect not) stay with
the local distributor.
>
Subscriptions.
Ive read that it really doesnt have a huge impact on a box, and that what
really matters is where the Distributor is. That Push or Pull is more for
Administrative type of stuff. Just not sure about this.
I just started at a company that uses quite a bit of replication. So far Ive
come up with two Publishers and propably or 6 or 8 Subscribers. The
Distributors are both Local and the Subscriptions are all Pull. It is all
Transactional Replication, some of it continuos, some every 15 minutes.
So my questions are:
Would I be better off to use a dedicated Remote Distributor? One of my main
objectives here is to speed up these boxes.
If I did use a Remote Distributor, would it matter if I went to Push
Subscriptions for centralized Administration? Or would that defeat my goal
of speeding up the Publisher?
I don't like remote distributors and hesitate before using them. If your
remote distributor goes down you can end up with ballooning tlogs on your
publication databases and you can have problems getting your log reader
agent working again.
If you have high throughput and are experiencing locking you might want to
look at them.
Pull subscriptions do lessen the load on the publisher. They are the best
solution when you have a lot of subscribers, are replicating across the
internet or when your subscribers are not well connected or not always
connected, you can live with no central point of administration (other than
replication monitor group).
the rest of the answers are inline.
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
"ChrisR" <noemail@.bla.com> wrote in message
news:%23ydW$eHNFHA.3668@.TK2MSFTNGP14.phx.gbl...
> I've always had a hard time getting my head around Push and Pull
> Subscriptions.
> Ive read that it really doesnt have a huge impact on a box, and that what
> really matters is where the Distributor is. That Push or Pull is more for
> Administrative type of stuff. Just not sure about this.
> I just started at a company that uses quite a bit of replication. So far
Ive
> come up with two Publishers and propably or 6 or 8 Subscribers. The
> Distributors are both Local and the Subscriptions are all Pull. It is all
> Transactional Replication, some of it continuos, some every 15 minutes.
> So my questions are:
> Would I be better off to use a dedicated Remote Distributor? One of my
main
> objectives here is to speed up these boxes.
I would only use this if you are experiencing considerable locking in your
distribution database.
> If I did use a Remote Distributor, would it matter if I went to Push
> Subscriptions for centralized Administration?
No, not for a few always connected subscribers.
Or would that defeat my goal
> of speeding up the Publisher?
Stop your log reader and distribution agent. Do you get a significant
increase in performance. If so, migrate; if not (and suspect not) stay with
the local distributor.
>
Friday, March 23, 2012
push error - urgent
I'm able to pull the metatdata down from my sql server to my handheld for table, I can then add data to that table on the handheld, when I try to push it back to Sql Server table I pulled from, I'm getting the following error message:
The Push method returned one or more error rows. See the specified error table. [ Error table name = ErrorTable ]
what does this mean, and how can I push my table back to the table I pulled from? I have trackingOn set on the pull process.
I'm getting the same error. Can anyone help?|||
When the SqlCeRemoteDataAccess.Push method encounters a problem it puts an error message in a database table. In your case the table is called "ErrorTable." (You can specify a different table name in the Pull method if you care to.)
Use Query Analyzer on the device to look at this table. The problem will probably be obvious when you see the full error message. If not, post the error message(s) in the forum.
Query Analyzer is supposed to be installed on the device automatically by Visual Studio when you do a debug build, but it isn't always. If you don't have it already, you can install it manually as described here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=314754&SiteID=1
The most common reasons for a push error are primary and foreign key constraint violations.
sqlpush error - urgent
I'm able to pull the metatdata down from my sql server to my handheld for table, I can then add data to that table on the handheld, when I try to push it back to Sql Server table I pulled from, I'm getting the following error message:
The Push method returned one or more error rows. See the specified error table. [ Error table name = ErrorTable ]
what does this mean, and how can I push my table back to the table I pulled from? I have trackingOn set on the pull process.
I'm getting the same error. Can anyone help?|||
When the SqlCeRemoteDataAccess.Push method encounters a problem it puts an error message in a database table. In your case the table is called "ErrorTable." (You can specify a different table name in the Pull method if you care to.)
Use Query Analyzer on the device to look at this table. The problem will probably be obvious when you see the full error message. If not, post the error message(s) in the forum.
Query Analyzer is supposed to be installed on the device automatically by Visual Studio when you do a debug build, but it isn't always. If you don't have it already, you can install it manually as described here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=314754&SiteID=1
The most common reasons for a push error are primary and foreign key constraint violations.
Push and Pull subscription?
As I understand replication in Sql2K the only difference in push or pull subscriptions is where the agent runs. If I wanted changes in the publisher to be sent to the subscribers immediately after the change then I thought push would be better. But, if I am equally interested in changes made at the subscriber then what should I use? Or does the agent monitor both the publisher and subscriber at the same time?
Thanks for your help
Graham
Graham, assuming you're talking about merge replication, changes will be propagated up/down whenever the agent runs. If you run the agent in continuous mode, then the changes should be sent within the polling period of the agent. If you run the agent in a scheduled mode, or on demand, then the changes will be sent when the agent runs.Tuesday, March 20, 2012
Pulling SQL Server information in C#
I'm looking to pull information such as uptime, ip, status, db name, etc from my sql server database to display on a form. I'd like to get more detailed if I could, such as current load on database, threads, etc. Does anyone know if this is possible using
C#?
Hi Chris,
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?
|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
C#?
Hi Chris,
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?
|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
Pulling SQL Server information in C#
I'm looking to pull information such as uptime, ip, status, db name, etc from my sql server database to display on a form. I'd like to get more detailed if I could, such as current load on database, threads, etc. Does anyone know if this is possible using C#?Hi Chris,
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
--
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> > I'm looking to pull information such as uptime, ip, status, db name, etc
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
--
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> > I'm looking to pull information such as uptime, ip, status, db name, etc
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
Pulling SQL Server information in C#
I'm looking to pull information such as uptime, ip, status, db name, etc fro
m my sql server database to display on a form. I'd like to get more detailed
if I could, such as current load on database, threads, etc. Does anyone kno
w if this is possible using
C#?Hi Chris,
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
--
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
m my sql server database to display on a form. I'd like to get more detailed
if I could, such as current load on database, threads, etc. Does anyone kno
w if this is possible using
C#?Hi Chris,
Most of these are retrieved via the @.@. variables. For a full list look in
BOL
Select @.@.CPU_BUSY
You may also want to look at sp_monitor
sp_monitor
I hope this helps
--
Greg O
Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
Document all your databases now.
http://www.ag-software.com/ags_scribe_index.aspx
Crosstab queries from SQL Server.
http://www.ag-software.com/xp_ags_crosstab.aspx
Edit Extended Properties as easy as can be.
http://www.ag-software.com/ags_SSEPE_index.aspx
"Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> I'm looking to pull information such as uptime, ip, status, db name, etc
from my sql server database to display on a form. I'd like to get more
detailed if I could, such as current load on database, threads, etc. Does
anyone know if this is possible using C#?|||Just to add - of course you can catch this info in C#. Stored procedures
give you rowsets and you can use DataReader to catch it; scalar values can
be caught as output parameters of the Command object.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Greg Obleshchuk" <greg-n-o-s-p-a-m-@.ag-s-o-f-t-w-a-r-e.com> wrote in
message news:uMFMbRyKEHA.2576@.TK2MSFTNGP12.phx.gbl...
> Hi Chris,
> Most of these are retrieved via the @.@. variables. For a full list look in
> BOL
> Select @.@.CPU_BUSY
> You may also want to look at sp_monitor
> sp_monitor
>
> --
> I hope this helps
> --
> Greg O
> Looking for SQL Scripts, Need Help? http://www.SQL-Scripts.com
> Document all your databases now.
> http://www.ag-software.com/ags_scribe_index.aspx
> Crosstab queries from SQL Server.
> http://www.ag-software.com/xp_ags_crosstab.aspx
> Edit Extended Properties as easy as can be.
> http://www.ag-software.com/ags_SSEPE_index.aspx
>
> "Chris Stewart" <CompiledMonkey@.comcast.net> wrote in message
> news:6D0351C3-76E2-4901-A269-630E89EAC66A@.microsoft.com...
> from my sql server database to display on a form. I'd like to get more
> detailed if I could, such as current load on database, threads, etc. Does
> anyone know if this is possible using C#?
>
Pulling SQL Server data from Unix
How can I pull data from a MSSQL server in UNIX. Do I need an entry in
.odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
ThanksSee this old post.
7dc3ba3fd9e90c" target="_blank">http://groups.google.co.in/group/co...
7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
.odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
ThanksSee this old post.
7dc3ba3fd9e90c" target="_blank">http://groups.google.co.in/group/co...
7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
Pulling SQL Server data from Unix
How can I pull data from a MSSQL server in UNIX. Do I need an entry in
.odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
ThanksSee this old post.
http://groups.google.co.in/group/comp.databases.ms-sqlserver/browse_thread/thread/218b790b3b3cffbf/5c7dc3ba3fd9e90c?q=accessing+sql+server+from+UNIX&rnum=1&hl=en#5c7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
.odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
ThanksSee this old post.
http://groups.google.co.in/group/comp.databases.ms-sqlserver/browse_thread/thread/218b790b3b3cffbf/5c7dc3ba3fd9e90c?q=accessing+sql+server+from+UNIX&rnum=1&hl=en#5c7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
Pulling SQL Server data from Unix
How can I pull data from a MSSQL server in UNIX. Do I need an entry in
..odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
Thanks
See this old post.
http://groups.google.co.in/group/com...7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
..odbc.ini, or other client tools to run a select on a table.
is this even possible
pls let me know
Thanks
See this old post.
http://groups.google.co.in/group/com...7dc3ba3fd9e90c
Thanks
Hari
SQL Server MVP
"Sanjay" <Sanjay@.discussions.microsoft.com> wrote in message
news:041F3647-E106-493A-8EDF-C0A2D83EEB87@.microsoft.com...
> How can I pull data from a MSSQL server in UNIX. Do I need an entry in
> .odbc.ini, or other client tools to run a select on a table.
> is this even possible
> pls let me know
> Thanks
>
Subscribe to:
Posts (Atom)