Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
Showing posts with label agent. Show all posts
Showing posts with label agent. Show all posts
Thursday, March 29, 2012
Do SQL Server's developers even know what the datetime datatype is?
Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
Do regular stored procedures still run when Agent XPs are disabled?
Gurus,
I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
following:
"SQL Server Agent (Agent XPs disabled)"
Agent XPs are extended stored procedures.
http://msdn2.microsoft.com/en-us/library/ms178127.aspx
My question is do regular stored procedures still run?
Spin
Spin,
Yes, they do. Agent XPs disable really means just the SQL Agent procedures
that SQL Agent uses to get its job done.
RLF
"Spin" <Spin@.invalid.com> wrote in message
news:647jmvF2ae2t8U1@.mid.individual.net...
> Gurus,
> I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
> following:
> "SQL Server Agent (Agent XPs disabled)"
> Agent XPs are extended stored procedures.
> http://msdn2.microsoft.com/en-us/library/ms178127.aspx
> My question is do regular stored procedures still run?
> --
> Spin
>
sql
I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
following:
"SQL Server Agent (Agent XPs disabled)"
Agent XPs are extended stored procedures.
http://msdn2.microsoft.com/en-us/library/ms178127.aspx
My question is do regular stored procedures still run?
Spin
Spin,
Yes, they do. Agent XPs disable really means just the SQL Agent procedures
that SQL Agent uses to get its job done.
RLF
"Spin" <Spin@.invalid.com> wrote in message
news:647jmvF2ae2t8U1@.mid.individual.net...
> Gurus,
> I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
> following:
> "SQL Server Agent (Agent XPs disabled)"
> Agent XPs are extended stored procedures.
> http://msdn2.microsoft.com/en-us/library/ms178127.aspx
> My question is do regular stored procedures still run?
> --
> Spin
>
sql
Do regular stored procedures still run when Agent XPs are disabled?
Gurus,
I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
following:
"SQL Server Agent (Agent XPs disabled)"
Agent XPs are extended stored procedures.
http://msdn2.microsoft.com/en-us/library/ms178127.aspx
My question is do regular stored procedures still run?
--
SpinSpin,
Yes, they do. Agent XPs disable really means just the SQL Agent procedures
that SQL Agent uses to get its job done.
RLF
"Spin" <Spin@.invalid.com> wrote in message
news:647jmvF2ae2t8U1@.mid.individual.net...
> Gurus,
> I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
> following:
> "SQL Server Agent (Agent XPs disabled)"
> Agent XPs are extended stored procedures.
> http://msdn2.microsoft.com/en-us/library/ms178127.aspx
> My question is do regular stored procedures still run?
> --
> Spin
>
I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
following:
"SQL Server Agent (Agent XPs disabled)"
Agent XPs are extended stored procedures.
http://msdn2.microsoft.com/en-us/library/ms178127.aspx
My question is do regular stored procedures still run?
--
SpinSpin,
Yes, they do. Agent XPs disable really means just the SQL Agent procedures
that SQL Agent uses to get its job done.
RLF
"Spin" <Spin@.invalid.com> wrote in message
news:647jmvF2ae2t8U1@.mid.individual.net...
> Gurus,
> I noticed when my SQL Server Agent is stopped, what appears in SSMS is the
> following:
> "SQL Server Agent (Agent XPs disabled)"
> Agent XPs are extended stored procedures.
> http://msdn2.microsoft.com/en-us/library/ms178127.aspx
> My question is do regular stored procedures still run?
> --
> Spin
>
Wednesday, March 7, 2012
Distriubtion Error on Stored Procedure
Setting up Transactional Replication.
Log Reader Agent successfull.
Snapshot Agent successfull.
Distribution Agent Error (Replication is failing because of this error. I don't know what is wrong with the stored procedure that causes it not to replicate):
Date 1/19/2007 10:28:13 AM
Log Job History (IS36-MMS_20061213-MMSRepTest-IS4-30)
Step ID 2
Server IS4
Job Name IS36-MMS_20061213-MMSRepTest-IS4-30
Step Name Run agent.
Duration 00:00:11
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
2007-01-19 16:28:24.700 Category:COMMAND
Source: Failed Command
Number:
Message: CREATE PROCEDURE "dbo"."spBTG_GetEventsSince"(@.EventMin datetime, @.BoatID int) AS
BEGIN
create table #TmpEvents
(
BoatHistoryID int null,
PositionID int null,
Event varchar(50) null,
EventDateTime datetime null,
Direction char(1) null,
River char(3) null,
Mile numeric(6,2) null
)
insert into #TmpEvents
select bh.BoatHistoryID, null, Event, EventDateTime, Direction, riverloc, mileloc
--jds 6/22/05 hardcoded index to fix it when you call it from vb
-- from
2007-01-19 16:28:24.700 Category:NULL
Source: Microsoft SQL Native Client
Number: 1018
Message: Incorrect syntax near 'index'. If this is intended as a part of a table hint, A WITH keyword and parenthesis are now required. See SQL Server Books Online for proper syntax.
Here is the entire source of the sp:
GO
CREATE PROCEDURE [dbo].[spBTG_GetEventsSince](@.EventMin datetime, @.BoatID int) AS
BEGIN
create table #TmpEvents
(
BoatHistoryID int null,
PositionID int null,
Event varchar(50) null,
EventDateTime datetime null,
Direction char(1) null,
River char(3) null,
Mile numeric(6,2) null
)
insert into #TmpEvents
select bh.BoatHistoryID, null, Event, EventDateTime, Direction, riverloc, mileloc
--jds 6/22/05 hardcoded index to fix it when you call it from vb
-- from mtsEventHistory eh (NOLOCK)
-- left join mtsBoatHistory bh (NOLOCK) on bh.EventID = eh.EventID
from mtsEventHistory eh (NOLOCK, index(PK_MtsEventHistory))
left join mtsBoatHistory bh (NOLOCK, index(IDX_MtsBoatHistory_BoatID)) on bh.EventID = eh.EventID
where EventDateTime > @.EventMin
and BoatID = @.BoatID
and voidflag = 0
And eh.Event IN ('Pickup','Drop','Log Exchange','Off-Layup','Off-Repair','On-Layup','On-Repair','Morning Log','Bt Trip Dir Chg','End Boat Charter Out', 'Begin Boat Charter Out', 'Begin Boat Charter In')
insert into #TmpEvents
select null,BoatPositionID, Description, PositionDateTime, Direction, river, mile
from mtsBoatPosition (NOLOCK)
where PositionDateTime > @.EventMin
and BoatID = @.BoatID
select * from #TmpEvents Order By EventDateTime
drop table #TmpEvents
END
Linda, you can either change the stored procedure definition in the script generated by the snapshot agent to the following:
CREATE PROCEDURE [dbo].[spBTG_GetEventsSince](@.EventMin datetime, @.BoatID int) AS
BEGIN
create table #TmpEvents
(
BoatHistoryID int null,
PositionID int null,
Event varchar(50) null,
EventDateTime datetime null,
Direction char(1) null,
River char(3) null,
Mile numeric(6,2) null
)
insert into #TmpEvents
select bh.BoatHistoryID, null, Event, EventDateTime, Direction, riverloc, mileloc
--jds 6/22/05 hardcoded index to fix it when you call it from vb
-- from mtsEventHistory eh (NOLOCK)
-- left join mtsBoatHistory bh (NOLOCK) on bh.EventID = eh.EventID
from mtsEventHistory eh with (NOLOCK, index(PK_MtsEventHistory))
left join mtsBoatHistory bh with (NOLOCK, index(IDX_MtsBoatHistory_BoatID)) on bh.EventID = eh.EventID
where EventDateTime > @.EventMin
and BoatID = @.BoatID
and voidflag = 0
And eh.Event IN ('Pickup','Drop','Log Exchange','Off-Layup','Off-Repair','On-Layup','On-Repair','Morning Log','Bt Trip Dir Chg','End Boat Charter Out', 'Begin Boat Charter Out', 'Begin Boat Charter In')
insert into #TmpEvents
select null,BoatPositionID, Description, PositionDateTime, Direction, river, mile
from mtsBoatPosition (NOLOCK)
where PositionDateTime > @.EventMin
and BoatID = @.BoatID
select * from #TmpEvents Order By EventDateTime
drop table #TmpEvents
END
Or, you can change the compatibility level of your subscriber database to 80 or lower.
-Raymond
|||Raymond,
This sp currently runs on SQL2000. However, before we implement replication, it will be running on 2005. Is the change "adding with" something that will be required for SQL 2005 or does it have to do with replication?
Linda
|||The use of the "with" keyword with query hints is a SQL2005 requirement that is not directly related to replication. As I mentioned before, you can always change the dbcmptlevel of your subscriber database to 80 or lower so the old syntax in your procedure can be accepted.
-Raymond
|||Raymond,
On the subscriber database, do I run this command:
EXEC sp_dbcmptlevel MMS_20061213, 80;
to change the cmptlevel?
I did that and now I am getting this error:
Command attempted:
/* ============================================================ */
/* View: vMcsHeaders */
/* ============================================================ */
CREATE VIEW "dbo"."vMcsHeaders" AS
/* VIEW: vMcsHeaders
ABSTRACT: Used by the Contract System to work with contract headers
AUTHOR DATE
EJB 3/31/98 Created
SRM 4/8/98 - Added Customer_Code
EJB 5/1/98 - added filter for only contracts that are not deleteme = 1
EJB 6/10/98 - Ad
(Transaction sequence number: 0x00046CEA0000F21D005600000000, Command ID: 3385)
Error messages:
Invalid object name 'McsDemurrageSetUp'. (Source: MSSQLServer, Error number: 208)
Get help: http://help/208
Invalid object name 'McsDemurrageSetUp'. (Source: MSSQLServer, Error number: 208)
Get help: http://help/208
I notice the McsDemurrageSetUp is it referencing is spelled McsDemurrageSetup. How do I track down what kind of error this is? (Perhaps, I did not get the compatibility set correctly to 80?)
|||It would appear that you are replicating from a case-insensitive database to a case-sensitive database, this is not a supported scenario.
|||Raymond,
If I run the command: sp_server_info, both databases say "MIXED" under identifier case. However, I did figure out the problem. The storedprocedure is referencing a table that was not replicated because it did not have a primary key. I did not notice that initially when I noticed the case was different. The database I am working with needs a lot of work before it can successfully be replicated!
Thanks,
Linda
distributor agent
Win2003srv
mssql2000
mssql2005
Oracle
I have a mssql2000 database that I Replicate to oracle,
some tables have row filtering.
This was working fine until I create an another publication and subscription
(transaction)
on the same database, for mssql2005 This subscription has the
loopback_detection = N'True',
After this, the Oracle subscription stop to work correctly
Tables with row filter are not replicated. In Repl Monitor everything looks
fine
I try to delete all publication and then re-crate it and start snap-shot for
oracle
The bulk copying are doing the right thing regarding filter-rows.
But the distributor agent will not work properly
I can see the log-reader pushing transaction to the distibutor , but nothing
happens
What is wrong her?
-roger
What do you see if you run a sp_browsereplcmds in the distribution database?
The oracle DML should be showing up here.
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
"Roger Nygrd" <roger@.askit.no> wrote in message
news:11uemak27qnmp5d@.corp.supernews.com...
> Win2003srv
> mssql2000
> mssql2005
> Oracle
> I have a mssql2000 database that I Replicate to oracle,
> some tables have row filtering.
> This was working fine until I create an another publication and
> subscription (transaction)
> on the same database, for mssql2005 This subscription has the
> loopback_detection = N'True',
> After this, the Oracle subscription stop to work correctly
> Tables with row filter are not replicated. In Repl Monitor everything
> looks fine
> I try to delete all publication and then re-crate it and start snap-shot
> for oracle
> The bulk copying are doing the right thing regarding filter-rows.
> But the distributor agent will not work properly
> I can see the log-reader pushing transaction to the distibutor , but
> nothing happens
> What is wrong her?
>
> -roger
>
|||It is empty
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23w5ntqyKGHA.2036@.TK2MSFTNGP14.phx.gbl...
> What do you see if you run a sp_browsereplcmds in the distribution
> database? The oracle DML should be showing up here.
> --
> 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
> "Roger Nygrd" <roger@.askit.no> wrote in message
> news:11uemak27qnmp5d@.corp.supernews.com...
>
mssql2000
mssql2005
Oracle
I have a mssql2000 database that I Replicate to oracle,
some tables have row filtering.
This was working fine until I create an another publication and subscription
(transaction)
on the same database, for mssql2005 This subscription has the
loopback_detection = N'True',
After this, the Oracle subscription stop to work correctly
Tables with row filter are not replicated. In Repl Monitor everything looks
fine
I try to delete all publication and then re-crate it and start snap-shot for
oracle
The bulk copying are doing the right thing regarding filter-rows.
But the distributor agent will not work properly
I can see the log-reader pushing transaction to the distibutor , but nothing
happens
What is wrong her?
-roger
What do you see if you run a sp_browsereplcmds in the distribution database?
The oracle DML should be showing up here.
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
"Roger Nygrd" <roger@.askit.no> wrote in message
news:11uemak27qnmp5d@.corp.supernews.com...
> Win2003srv
> mssql2000
> mssql2005
> Oracle
> I have a mssql2000 database that I Replicate to oracle,
> some tables have row filtering.
> This was working fine until I create an another publication and
> subscription (transaction)
> on the same database, for mssql2005 This subscription has the
> loopback_detection = N'True',
> After this, the Oracle subscription stop to work correctly
> Tables with row filter are not replicated. In Repl Monitor everything
> looks fine
> I try to delete all publication and then re-crate it and start snap-shot
> for oracle
> The bulk copying are doing the right thing regarding filter-rows.
> But the distributor agent will not work properly
> I can see the log-reader pushing transaction to the distibutor , but
> nothing happens
> What is wrong her?
>
> -roger
>
|||It is empty
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23w5ntqyKGHA.2036@.TK2MSFTNGP14.phx.gbl...
> What do you see if you run a sp_browsereplcmds in the distribution
> database? The oracle DML should be showing up here.
> --
> 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
> "Roger Nygrd" <roger@.askit.no> wrote in message
> news:11uemak27qnmp5d@.corp.supernews.com...
>
Distribution Subsystem: agent (null) failed.
Win 2k & SQL 2k SP3a
This error appears in my Application Log. How can I fix/remove/delete
this? How can I determine what dB this is from?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Type:Error
Event Source:MSSQLSERVER
Event Category:(2)
Event ID:17052
Date:12/23/2005
Time:8:00:11 AM
User:ROUSES.COM\Administrator
Computer:ROUSEONE
Description:
Error: 14151, Severity: 18, State: 1
Replication-Replication Distribution Subsystem: agent (null) failed.
The subscription to publication '(null)' has expired and does not
exist.
Data:
0000: 47 37 00 00 12 00 00 00 G7.....
0008: 09 00 00 00 52 00 4f 00 ...R.O.
0010: 55 00 53 00 45 00 4f 00 U.S.E.O.
0018: 4e 00 45 00 00 00 0d 00 N.E....
0020: 00 00 64 00 69 00 73 00 ..d.i.s.
0028: 74 00 72 00 69 00 62 00 t.r.i.b.
0030: 75 00 74 00 69 00 6f 00 u.t.i.o.
0038: 6e 00 00 00 n...
Run your agents one by one to see if you can manually force this error in
your event log.
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
"LPR-3rd" <lreames@.gmail.com> wrote in message
news:1135354198.113526.29560@.z14g2000cwz.googlegro ups.com...
> Win 2k & SQL 2k SP3a
> This error appears in my Application Log. How can I fix/remove/delete
> this? How can I determine what dB this is from?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 17052
> Date: 12/23/2005
> Time: 8:00:11 AM
> User: ROUSES.COM\Administrator
> Computer: ROUSEONE
> Description:
> Error: 14151, Severity: 18, State: 1
> Replication-Replication Distribution Subsystem: agent (null) failed.
> The subscription to publication '(null)' has expired and does not
> exist.
> Data:
> 0000: 47 37 00 00 12 00 00 00 G7.....
> 0008: 09 00 00 00 52 00 4f 00 ...R.O.
> 0010: 55 00 53 00 45 00 4f 00 U.S.E.O.
> 0018: 4e 00 45 00 00 00 0d 00 N.E....
> 0020: 00 00 64 00 69 00 73 00 ..d.i.s.
> 0028: 74 00 72 00 69 00 62 00 t.r.i.b.
> 0030: 75 00 74 00 69 00 6f 00 u.t.i.o.
> 0038: 6e 00 00 00 n...
>
This error appears in my Application Log. How can I fix/remove/delete
this? How can I determine what dB this is from?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Type:Error
Event Source:MSSQLSERVER
Event Category:(2)
Event ID:17052
Date:12/23/2005
Time:8:00:11 AM
User:ROUSES.COM\Administrator
Computer:ROUSEONE
Description:
Error: 14151, Severity: 18, State: 1
Replication-Replication Distribution Subsystem: agent (null) failed.
The subscription to publication '(null)' has expired and does not
exist.
Data:
0000: 47 37 00 00 12 00 00 00 G7.....
0008: 09 00 00 00 52 00 4f 00 ...R.O.
0010: 55 00 53 00 45 00 4f 00 U.S.E.O.
0018: 4e 00 45 00 00 00 0d 00 N.E....
0020: 00 00 64 00 69 00 73 00 ..d.i.s.
0028: 74 00 72 00 69 00 62 00 t.r.i.b.
0030: 75 00 74 00 69 00 6f 00 u.t.i.o.
0038: 6e 00 00 00 n...
Run your agents one by one to see if you can manually force this error in
your event log.
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
"LPR-3rd" <lreames@.gmail.com> wrote in message
news:1135354198.113526.29560@.z14g2000cwz.googlegro ups.com...
> Win 2k & SQL 2k SP3a
> This error appears in my Application Log. How can I fix/remove/delete
> this? How can I determine what dB this is from?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 17052
> Date: 12/23/2005
> Time: 8:00:11 AM
> User: ROUSES.COM\Administrator
> Computer: ROUSEONE
> Description:
> Error: 14151, Severity: 18, State: 1
> Replication-Replication Distribution Subsystem: agent (null) failed.
> The subscription to publication '(null)' has expired and does not
> exist.
> Data:
> 0000: 47 37 00 00 12 00 00 00 G7.....
> 0008: 09 00 00 00 52 00 4f 00 ...R.O.
> 0010: 55 00 53 00 45 00 4f 00 U.S.E.O.
> 0018: 4e 00 45 00 00 00 0d 00 N.E....
> 0020: 00 00 64 00 69 00 73 00 ..d.i.s.
> 0028: 74 00 72 00 69 00 62 00 t.r.i.b.
> 0030: 75 00 74 00 69 00 6f 00 u.t.i.o.
> 0038: 6e 00 00 00 n...
>
Saturday, February 25, 2012
Distribution job failed
When the distribution agent runs trying to apply the snapshot at the subscriber I get the following error 20253 sql 2005
End of file reached , terminator missing or field data incomplete in SQL 2005
Consult the BOL for more information on the bcp utility and its supported options.
To obtain an error file with details on the errors encountered when initializing the subscribing table, execute the bcp command that appears below.
Consult the BOL for more information on the bcp utility and its supported options.
It could be that the snapshot files for one of your articles is corrupted. Try manually deleting the snapshot files from the snapshot folder and start over - regenerate the snapshot and try to apply it.
If it still fails, you need to tell us what's different about the article that's failing: what kinds of datatypes are in the table, did you manually edit any of the bcp files, what kind of subscriber is this, is this oracle publisher, etc.
|||Hi,
Did you ever get this issue sorted?
I am receiving the same error message on 1 table during the snapshot sync phase on SQL2005 and it is failing the sync.
Cheers
Distribution job failed
When the distribution agent runs trying to apply the snapshot at the subscriber I get the following error 20253 sql 2005
End of file reached , terminator missing or field data incomplete in SQL 2005
Consult the BOL for more information on the bcp utility and its supported options.
To obtain an error file with details on the errors encountered when initializing the subscribing table, execute the bcp command that appears below.
Consult the BOL for more information on the bcp utility and its supported options.
It could be that the snapshot files for one of your articles is corrupted. Try manually deleting the snapshot files from the snapshot folder and start over - regenerate the snapshot and try to apply it.
If it still fails, you need to tell us what's different about the article that's failing: what kinds of datatypes are in the table, did you manually edit any of the bcp files, what kind of subscriber is this, is this oracle publisher, etc.
|||Hi,
Did you ever get this issue sorted?
I am receiving the same error message on 1 table during the snapshot sync phase on SQL2005 and it is failing the sync.
Cheers
distribution database having problems??
Something is wrong with my distribtion database. When the distribution clean
up agent runs (or I run dbo.sp_MSdistribution_cleanup manually)
I get the following error message:
Executed as user: sa. Table error: Database ID 9, object ID 5575058, index
ID 1. Chain linkage mismatch. (1:89299)->next = (1:59339), but
(1:59339)->prev = (0:0). [SQLSTATE HY000] (Error 8908). The step failed.
SO then I run
DBCC CHECKDB
on the distribution database. The MSrepl_commands is the table with the
problem with repeated messages such as:
Table error: Object ID 5575058, index ID 1. B-tree page (1:91019) has two
parent nodes (1:93624), slot 103 and (1:89299), slot 1.
I run this:
dbcc checktable ('MSrepl_commands')
and get the same type of error message.
I have no idea how to fix this. Any advise?? (If I try and use the repair
options of the dbcc commands than it says I have to have the DB in single
user mode. Not sure if you are even suppose to do that with a distribution
db?)
Thanks so much for any and all help,
Kristy
Believe it or not these problems crop up from time to time on replicated
databases. Stop the sql server agent on the publisher, yank the network
cable (if possible), and put this database in single user mode and do the
repair.
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
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:OCFMw7kPGHA.1696@.TK2MSFTNGP14.phx.gbl...
> Something is wrong with my distribtion database. When the distribution
> clean
> up agent runs (or I run dbo.sp_MSdistribution_cleanup manually)
> I get the following error message:
> Executed as user: sa. Table error: Database ID 9, object ID 5575058, index
> ID 1. Chain linkage mismatch. (1:89299)->next = (1:59339), but
> (1:59339)->prev = (0:0). [SQLSTATE HY000] (Error 8908). The step failed.
> SO then I run
> DBCC CHECKDB
> on the distribution database. The MSrepl_commands is the table with the
> problem with repeated messages such as:
> Table error: Object ID 5575058, index ID 1. B-tree page (1:91019) has two
> parent nodes (1:93624), slot 103 and (1:89299), slot 1.
> I run this:
> dbcc checktable ('MSrepl_commands')
> and get the same type of error message.
> I have no idea how to fix this. Any advise?? (If I try and use the
> repair
> options of the dbcc commands than it says I have to have the DB in single
> user mode. Not sure if you are even suppose to do that with a distribution
> db?)
> Thanks so much for any and all help,
> Kristy
>
>
|||Thanks Hilary. I will check to see if we can yank the network cable. Not
sure if we can though because it is on a remote server hosted by another
company in another state.
If not, is there something else I can do? (Besides redo replication and drop
the distribution DB.)
As always, thanks!
--Kristy
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eODseSmPGHA.5516@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Believe it or not these problems crop up from time to time on replicated
> databases. Stop the sql server agent on the publisher, yank the network
> cable (if possible), and put this database in single user mode and do the
> repair.
> --
> 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
>
> "Kristy" <pleasereplyby@.posting.com> wrote in message
> news:OCFMw7kPGHA.1696@.TK2MSFTNGP14.phx.gbl...
index[vbcol=seagreen]
failed.[vbcol=seagreen]
two[vbcol=seagreen]
single[vbcol=seagreen]
distribution
>
up agent runs (or I run dbo.sp_MSdistribution_cleanup manually)
I get the following error message:
Executed as user: sa. Table error: Database ID 9, object ID 5575058, index
ID 1. Chain linkage mismatch. (1:89299)->next = (1:59339), but
(1:59339)->prev = (0:0). [SQLSTATE HY000] (Error 8908). The step failed.
SO then I run
DBCC CHECKDB
on the distribution database. The MSrepl_commands is the table with the
problem with repeated messages such as:
Table error: Object ID 5575058, index ID 1. B-tree page (1:91019) has two
parent nodes (1:93624), slot 103 and (1:89299), slot 1.
I run this:
dbcc checktable ('MSrepl_commands')
and get the same type of error message.
I have no idea how to fix this. Any advise?? (If I try and use the repair
options of the dbcc commands than it says I have to have the DB in single
user mode. Not sure if you are even suppose to do that with a distribution
db?)
Thanks so much for any and all help,
Kristy
Believe it or not these problems crop up from time to time on replicated
databases. Stop the sql server agent on the publisher, yank the network
cable (if possible), and put this database in single user mode and do the
repair.
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
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:OCFMw7kPGHA.1696@.TK2MSFTNGP14.phx.gbl...
> Something is wrong with my distribtion database. When the distribution
> clean
> up agent runs (or I run dbo.sp_MSdistribution_cleanup manually)
> I get the following error message:
> Executed as user: sa. Table error: Database ID 9, object ID 5575058, index
> ID 1. Chain linkage mismatch. (1:89299)->next = (1:59339), but
> (1:59339)->prev = (0:0). [SQLSTATE HY000] (Error 8908). The step failed.
> SO then I run
> DBCC CHECKDB
> on the distribution database. The MSrepl_commands is the table with the
> problem with repeated messages such as:
> Table error: Object ID 5575058, index ID 1. B-tree page (1:91019) has two
> parent nodes (1:93624), slot 103 and (1:89299), slot 1.
> I run this:
> dbcc checktable ('MSrepl_commands')
> and get the same type of error message.
> I have no idea how to fix this. Any advise?? (If I try and use the
> repair
> options of the dbcc commands than it says I have to have the DB in single
> user mode. Not sure if you are even suppose to do that with a distribution
> db?)
> Thanks so much for any and all help,
> Kristy
>
>
|||Thanks Hilary. I will check to see if we can yank the network cable. Not
sure if we can though because it is on a remote server hosted by another
company in another state.
If not, is there something else I can do? (Besides redo replication and drop
the distribution DB.)
As always, thanks!
--Kristy
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eODseSmPGHA.5516@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Believe it or not these problems crop up from time to time on replicated
> databases. Stop the sql server agent on the publisher, yank the network
> cable (if possible), and put this database in single user mode and do the
> repair.
> --
> 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
>
> "Kristy" <pleasereplyby@.posting.com> wrote in message
> news:OCFMw7kPGHA.1696@.TK2MSFTNGP14.phx.gbl...
index[vbcol=seagreen]
failed.[vbcol=seagreen]
two[vbcol=seagreen]
single[vbcol=seagreen]
distribution
>
Friday, February 24, 2012
distribution agent works for one db but timed out for another db
Hi friends,
Can someone help me on this? I have set up transactional repl between the
primary site and secondary site for 2 databases. Both transactional repls are
bi-directional. Now the publication for one db works file but it did not work
for another db. The distribution agent was saying "time out expired" during
the initialization. I had modified QueryTimeout from 300 to 4800 which made
the subscriber's transaction log dramatically increase. My question is why it
works on one database but did not work on another one (this is bigger size).
both dbs stay on the same machines. Publisher and Distributor are the same
machine but the Subscriber is running on a separate one.
Thanks in advances,
Perhaps modify the LoginTimeout as well.
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
"FYK" <FYK@.discussions.microsoft.com> wrote in message
news:3F2213CE-63A2-45B8-A267-8E370F7CCEFC@.microsoft.com...
> Hi friends,
> Can someone help me on this? I have set up transactional repl between the
> primary site and secondary site for 2 databases. Both transactional repls
are
> bi-directional. Now the publication for one db works file but it did not
work
> for another db. The distribution agent was saying "time out expired"
during
> the initialization. I had modified QueryTimeout from 300 to 4800 which
made
> the subscriber's transaction log dramatically increase. My question is why
it
> works on one database but did not work on another one (this is bigger
size).
> both dbs stay on the same machines. Publisher and Distributor are the same
> machine but the Subscriber is running on a separate one.
> Thanks in advances,
Can someone help me on this? I have set up transactional repl between the
primary site and secondary site for 2 databases. Both transactional repls are
bi-directional. Now the publication for one db works file but it did not work
for another db. The distribution agent was saying "time out expired" during
the initialization. I had modified QueryTimeout from 300 to 4800 which made
the subscriber's transaction log dramatically increase. My question is why it
works on one database but did not work on another one (this is bigger size).
both dbs stay on the same machines. Publisher and Distributor are the same
machine but the Subscriber is running on a separate one.
Thanks in advances,
Perhaps modify the LoginTimeout as well.
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
"FYK" <FYK@.discussions.microsoft.com> wrote in message
news:3F2213CE-63A2-45B8-A267-8E370F7CCEFC@.microsoft.com...
> Hi friends,
> Can someone help me on this? I have set up transactional repl between the
> primary site and secondary site for 2 databases. Both transactional repls
are
> bi-directional. Now the publication for one db works file but it did not
work
> for another db. The distribution agent was saying "time out expired"
during
> the initialization. I had modified QueryTimeout from 300 to 4800 which
made
> the subscriber's transaction log dramatically increase. My question is why
it
> works on one database but did not work on another one (this is bigger
size).
> both dbs stay on the same machines. Publisher and Distributor are the same
> machine but the Subscriber is running on a separate one.
> Thanks in advances,
Distribution Agent TimeOut
I have setup pull transactional replication with multiple publications and
distribution agents.
One of my distribution agent always says the following error--
Timeout expired
(Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
while other agents are executed just fine..
any suggestions..?
Regards,
bump up LoginTimeout and QueryTimeout to 120.
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
"SQL Replication Guy" <SQLReplicationGuy@.discussions.microsoft.com> wrote in
message news:65DC7C0C-6149-4DB0-8C28-06DAC9EAAA59@.microsoft.com...
> I have setup pull transactional replication with multiple publications and
> distribution agents.
> One of my distribution agent always says the following error--
> --
> Timeout expired
> (Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
> --
> while other agents are executed just fine..
> any suggestions..?
> Regards,
distribution agents.
One of my distribution agent always says the following error--
Timeout expired
(Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
while other agents are executed just fine..
any suggestions..?
Regards,
bump up LoginTimeout and QueryTimeout to 120.
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
"SQL Replication Guy" <SQLReplicationGuy@.discussions.microsoft.com> wrote in
message news:65DC7C0C-6149-4DB0-8C28-06DAC9EAAA59@.microsoft.com...
> I have setup pull transactional replication with multiple publications and
> distribution agents.
> One of my distribution agent always says the following error--
> --
> Timeout expired
> (Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
> --
> while other agents are executed just fine..
> any suggestions..?
> Regards,
Distribution Agent Stopped Working
I recently started having an issue with a distribution agent I have setup. I
am doing a simple transactional replication of a production database to
another server at a different location. A few days ago I started to receive
the error message " Error 14262:The
specified@.job_id('5E6241B8-55E2-472F-A3B9-346B7B66CFF5') does not exist"
whenever I tried to restart the distibution agent. It seems like the agent
was stopped a few days ago and now it cannot be restarted because of a
missing job. Can I recreate the agent and the job it is looking for? Or can I
recreate just the job and have the agent use that?
It seem like this job no longer exists. I do not see any reference to this id
in the sysjobs table. I do see a job in the sql server agent that performs
the same replication I am having problems with, but I believe this job is
from my attempts to recreate replication. The original job is not there. We
do have consultants that script things against our server, but as of yet none
of them have admitted to doing anything. Is it possible to recreate the job
that this agent is referencing or point it to the other job that is
performing the same function?
"Paul Ibison" wrote:
> I can't understnad how this can occur and would like to better understand
> it. Does the job id ('5E6241B8-55E2-472F-A3B9-346B7B66CFF5') exist in
> sysjobs? Can you start the job from sql server agent? If so,then it is the
> mapping of the logical distribution agent to the physical job that has gon
> awry. Has anything changed in the configuration recently - anyone scripted
> in the replication setup perhaps?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
>
|||Have a look at syssubscriptions - the distribution_jobid column. It might be
that you could update this with the id of the job which is correct for you.
We're not really supposed to edit this type of info of course and the
supported mechanism would be to reinitialize.
Cheers,
Paul Ibison
am doing a simple transactional replication of a production database to
another server at a different location. A few days ago I started to receive
the error message " Error 14262:The
specified@.job_id('5E6241B8-55E2-472F-A3B9-346B7B66CFF5') does not exist"
whenever I tried to restart the distibution agent. It seems like the agent
was stopped a few days ago and now it cannot be restarted because of a
missing job. Can I recreate the agent and the job it is looking for? Or can I
recreate just the job and have the agent use that?
It seem like this job no longer exists. I do not see any reference to this id
in the sysjobs table. I do see a job in the sql server agent that performs
the same replication I am having problems with, but I believe this job is
from my attempts to recreate replication. The original job is not there. We
do have consultants that script things against our server, but as of yet none
of them have admitted to doing anything. Is it possible to recreate the job
that this agent is referencing or point it to the other job that is
performing the same function?
"Paul Ibison" wrote:
> I can't understnad how this can occur and would like to better understand
> it. Does the job id ('5E6241B8-55E2-472F-A3B9-346B7B66CFF5') exist in
> sysjobs? Can you start the job from sql server agent? If so,then it is the
> mapping of the logical distribution agent to the physical job that has gon
> awry. Has anything changed in the configuration recently - anyone scripted
> in the replication setup perhaps?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
>
|||Have a look at syssubscriptions - the distribution_jobid column. It might be
that you could update this with the id of the job which is correct for you.
We're not really supposed to edit this type of info of course and the
supported mechanism would be to reinitialize.
Cheers,
Paul Ibison
Distribution Agent Startup Parameters
Hello,
I have scenario where I use two servers: SQL 2K sp4, on Win2K3 sp1. One
server is a publisher, the other a subscriber. The replication topology is
Transaction Replication with 1 queued updating subscriber. The distribution
agent resides on the publisher.
Firstly, I am aware of nosync replication, but my environment requires some
more testing before I can implement it, because I can't take the publisher
offline, and I believe some tweaks are needed to ensure that the data will
truly be in sync. This said, one of my publications has a table article with
234 million records to transfer when the article is reinitialized. I am
having problems with the transaction log growing so large on the subscriber,
that it consumes all server space, and effectively kills the distribution
agent.
To mitigate this, I have tried to use the -BcpBatchSize parameter to try to
get the rows per batch down to manageable size so that I can manually shrink
the transaction log intermittantly while the distribution agent is applying
the snapshot. My strategy is not working.
Questions:
1) does -BcpBatchSize directly control the application of the snapshotted
article's transaction commit size, or is this parameter used outside of the
distribution agent's application of a snapshot?
2) does using -UseInprocLoader affect the -BcpBatchSize parameter? I ask
because bulk insert is different from bcp.
3) would -CommitBatchSize be a more appropriate setting to allow me to
actively manage the transaction log on the subscriber while this huge table
is being transferred?
Thanks for any input,
John T
If you are using concurrent snapshot on SQL2000, your only hope will be to
make sure that you hit the minimal logging code path when the snapshot is
delivered to the subscriber as the *entire* snapshot will be applied in an
atomic transaction. At the risk of telling you something that you may know
already, this means that you need to:
1) Make sure that 'select into\bulk copy' is enabled at the subscriber
database
2) The target table is empty with at most one index or not having any
indexes when the bulk copy occurs. This may be tricky to enforce as the
SQL2000 index creation logic in the distribution agent is not very precise.
You may want to modify the .idx scripts to leave only the primary key index
and then manually create other indexes afterwards.
3) Set -BcpBatchSize to be *larger* than the maximum number of rows in your
published tables. 2^31 - delta should work fine. Notice that you may start
seeing "Agent is waiting for database backend.." messages since the
distribution agent will not be able to log any progress messages until the
entire bulk load operation is done. You have also want to increase
the -QueryTimeout of the distribution agent.
-Raymond
"John T" <JohnT@.discussions.microsoft.com> wrote in message
news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
> Hello,
> I have scenario where I use two servers: SQL 2K sp4, on Win2K3 sp1. One
> server is a publisher, the other a subscriber. The replication topology
> is
> Transaction Replication with 1 queued updating subscriber. The
> distribution
> agent resides on the publisher.
> Firstly, I am aware of nosync replication, but my environment requires
> some
> more testing before I can implement it, because I can't take the publisher
> offline, and I believe some tweaks are needed to ensure that the data will
> truly be in sync. This said, one of my publications has a table article
> with
> 234 million records to transfer when the article is reinitialized. I am
> having problems with the transaction log growing so large on the
> subscriber,
> that it consumes all server space, and effectively kills the distribution
> agent.
> To mitigate this, I have tried to use the -BcpBatchSize parameter to try
> to
> get the rows per batch down to manageable size so that I can manually
> shrink
> the transaction log intermittantly while the distribution agent is
> applying
> the snapshot. My strategy is not working.
> Questions:
> 1) does -BcpBatchSize directly control the application of the snapshotted
> article's transaction commit size, or is this parameter used outside of
> the
> distribution agent's application of a snapshot?
> 2) does using -UseInprocLoader affect the -BcpBatchSize parameter? I ask
> because bulk insert is different from bcp.
> 3) would -CommitBatchSize be a more appropriate setting to allow me to
> actively manage the transaction log on the subscriber while this huge
> table
> is being transferred?
> Thanks for any input,
> John T
|||Hi Raymond, I though bcpBatchSize is analogous to the batchsize in bcp,
which means that it controls how many rows will be applied at a time in a
batch. Won't setting it to a large value create a very large transaction log
for large tables?
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:evddMLk8GHA.4084@.TK2MSFTNGP05.phx.gbl...
> If you are using concurrent snapshot on SQL2000, your only hope will be to
> make sure that you hit the minimal logging code path when the snapshot is
> delivered to the subscriber as the *entire* snapshot will be applied in an
> atomic transaction. At the risk of telling you something that you may know
> already, this means that you need to:
> 1) Make sure that 'select into\bulk copy' is enabled at the subscriber
> database
> 2) The target table is empty with at most one index or not having any
> indexes when the bulk copy occurs. This may be tricky to enforce as the
> SQL2000 index creation logic in the distribution agent is not very
> precise. You may want to modify the .idx scripts to leave only the primary
> key index and then manually create other indexes afterwards.
> 3) Set -BcpBatchSize to be *larger* than the maximum number of rows in
> your published tables. 2^31 - delta should work fine. Notice that you may
> start seeing "Agent is waiting for database backend.." messages since the
> distribution agent will not be able to log any progress messages until the
> entire bulk load operation is done. You have also want to increase
> the -QueryTimeout of the distribution agent.
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
>
|||Hilary, what you said is true, but the goal of my reccomendations is not to
have small transactions but to hit the minimal logging (or bulk-logged) code
path in the server which is the only feasible way to have a manageable log
size when a concurrent snapshot is applied in SQL2000. If a small batch size
is specified, the server will see the target table as non-empty after the
first batch is loaded and start going down the fully-logged code path after
that. And since there is an outer transaction bounding the delivery of a
concurrent snapshot in SQL2000, the log simply cannot be truncated even with
a small bcp batch size. I can understand why you think this is
counter-intuitive, but my suggestion had worked on a few occasions before
including the following:
http://groups.google.com/group/micro... e49f1fb79fe5
-Raymond
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uuGAtgk8GHA.2316@.TK2MSFTNGP04.phx.gbl...
> Hi Raymond, I though bcpBatchSize is analogous to the batchsize in bcp,
> which means that it controls how many rows will be applied at a time in a
> batch. Won't setting it to a large value create a very large transaction
> log for large tables?
> --
> 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
> "Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
> news:evddMLk8GHA.4084@.TK2MSFTNGP05.phx.gbl...
>
|||Ok, got it! Thanks Raymond. Still waiting on that beer you owe me;)
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:Oy1jKJl8GHA.2120@.TK2MSFTNGP03.phx.gbl...
> Hilary, what you said is true, but the goal of my reccomendations is not
> to have small transactions but to hit the minimal logging (or bulk-logged)
> code path in the server which is the only feasible way to have a
> manageable log size when a concurrent snapshot is applied in SQL2000. If a
> small batch size is specified, the server will see the target table as
> non-empty after the first batch is loaded and start going down the
> fully-logged code path after that. And since there is an outer transaction
> bounding the delivery of a concurrent snapshot in SQL2000, the log simply
> cannot be truncated even with a small bcp batch size. I can understand why
> you think this is counter-intuitive, but my suggestion had worked on a few
> occasions before including the following:
> http://groups.google.com/group/micro... e49f1fb79fe5
> -Raymond
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uuGAtgk8GHA.2316@.TK2MSFTNGP04.phx.gbl...
>
|||Raymond,
Just a couple of points of clarification:
1) If I am using simple recovery mode, I should get the same benefits in
this case as using bulk recovery mode, correct?
2) If I choose the schema option to drop the tables before the snapshot is
applied, this should meet all of the requirements in your second point,
correct?
3) Regarding the -BcpBatchSize setting of 2^31 - delta, what is the delta,
my desired batch commit size?
Thanks
John T
"Raymond Mak [MSFT]" wrote:
> If you are using concurrent snapshot on SQL2000, your only hope will be to
> make sure that you hit the minimal logging code path when the snapshot is
> delivered to the subscriber as the *entire* snapshot will be applied in an
> atomic transaction. At the risk of telling you something that you may know
> already, this means that you need to:
> 1) Make sure that 'select into\bulk copy' is enabled at the subscriber
> database
> 2) The target table is empty with at most one index or not having any
> indexes when the bulk copy occurs. This may be tricky to enforce as the
> SQL2000 index creation logic in the distribution agent is not very precise.
> You may want to modify the .idx scripts to leave only the primary key index
> and then manually create other indexes afterwards.
> 3) Set -BcpBatchSize to be *larger* than the maximum number of rows in your
> published tables. 2^31 - delta should work fine. Notice that you may start
> seeing "Agent is waiting for database backend.." messages since the
> distribution agent will not be able to log any progress messages until the
> entire bulk load operation is done. You have also want to increase
> the -QueryTimeout of the distribution agent.
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
>
>
|||Hi John,
In response to your inquiry:
1) Simple recovery mode is fine.
2) You may still need to make sure that only the primary key index got
created since the index creation logic in SQL2000 distribution agent is not
as optimal as it can be.
3) Delta is just a small number, you only need to make sure that the
resulting bcpbatchsize is bigger than the maximum number of rows in any of
your tables
Hope that helps,
-Raymond
"John T" <JohnT@.discussions.microsoft.com> wrote in message
news:A677C2FE-F672-4473-9B2E-725AFE500039@.microsoft.com...[vbcol=seagreen]
> Raymond,
> Just a couple of points of clarification:
> 1) If I am using simple recovery mode, I should get the same benefits in
> this case as using bulk recovery mode, correct?
> 2) If I choose the schema option to drop the tables before the snapshot is
> applied, this should meet all of the requirements in your second point,
> correct?
> 3) Regarding the -BcpBatchSize setting of 2^31 - delta, what is the delta,
> my desired batch commit size?
> Thanks
> John T
> "Raymond Mak [MSFT]" wrote:
|||Wait a minute, I think you are the one who owe me a beer, and I have proof
for that...
http://groups.google.com/group/micro... c299fb7328e2d
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23yI5FQr8GHA.3820@.TK2MSFTNGP02.phx.gbl...
> Ok, got it! Thanks Raymond. Still waiting on that beer you owe me;)
> --
> 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
>
> "Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
> news:Oy1jKJl8GHA.2120@.TK2MSFTNGP03.phx.gbl...
>
|||freaking Google.
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:enfPtCt8GHA.1492@.TK2MSFTNGP02.phx.gbl...
> Wait a minute, I think you are the one who owe me a beer, and I have proof
> for that...
> http://groups.google.com/group/micro... c299fb7328e2d
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23yI5FQr8GHA.3820@.TK2MSFTNGP02.phx.gbl...
>
|||This suggestion worked excellently. I went from filling up over 275 gigs of
drive space trying to deploy these large tables, to only using 975 megs of
drive space.
Thank you,
John T
"Raymond Mak [MSFT]" wrote:
> Hi John,
> In response to your inquiry:
> 1) Simple recovery mode is fine.
> 2) You may still need to make sure that only the primary key index got
> created since the index creation logic in SQL2000 distribution agent is not
> as optimal as it can be.
> 3) Delta is just a small number, you only need to make sure that the
> resulting bcpbatchsize is bigger than the maximum number of rows in any of
> your tables
> Hope that helps,
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:A677C2FE-F672-4473-9B2E-725AFE500039@.microsoft.com...
>
>
I have scenario where I use two servers: SQL 2K sp4, on Win2K3 sp1. One
server is a publisher, the other a subscriber. The replication topology is
Transaction Replication with 1 queued updating subscriber. The distribution
agent resides on the publisher.
Firstly, I am aware of nosync replication, but my environment requires some
more testing before I can implement it, because I can't take the publisher
offline, and I believe some tweaks are needed to ensure that the data will
truly be in sync. This said, one of my publications has a table article with
234 million records to transfer when the article is reinitialized. I am
having problems with the transaction log growing so large on the subscriber,
that it consumes all server space, and effectively kills the distribution
agent.
To mitigate this, I have tried to use the -BcpBatchSize parameter to try to
get the rows per batch down to manageable size so that I can manually shrink
the transaction log intermittantly while the distribution agent is applying
the snapshot. My strategy is not working.
Questions:
1) does -BcpBatchSize directly control the application of the snapshotted
article's transaction commit size, or is this parameter used outside of the
distribution agent's application of a snapshot?
2) does using -UseInprocLoader affect the -BcpBatchSize parameter? I ask
because bulk insert is different from bcp.
3) would -CommitBatchSize be a more appropriate setting to allow me to
actively manage the transaction log on the subscriber while this huge table
is being transferred?
Thanks for any input,
John T
If you are using concurrent snapshot on SQL2000, your only hope will be to
make sure that you hit the minimal logging code path when the snapshot is
delivered to the subscriber as the *entire* snapshot will be applied in an
atomic transaction. At the risk of telling you something that you may know
already, this means that you need to:
1) Make sure that 'select into\bulk copy' is enabled at the subscriber
database
2) The target table is empty with at most one index or not having any
indexes when the bulk copy occurs. This may be tricky to enforce as the
SQL2000 index creation logic in the distribution agent is not very precise.
You may want to modify the .idx scripts to leave only the primary key index
and then manually create other indexes afterwards.
3) Set -BcpBatchSize to be *larger* than the maximum number of rows in your
published tables. 2^31 - delta should work fine. Notice that you may start
seeing "Agent is waiting for database backend.." messages since the
distribution agent will not be able to log any progress messages until the
entire bulk load operation is done. You have also want to increase
the -QueryTimeout of the distribution agent.
-Raymond
"John T" <JohnT@.discussions.microsoft.com> wrote in message
news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
> Hello,
> I have scenario where I use two servers: SQL 2K sp4, on Win2K3 sp1. One
> server is a publisher, the other a subscriber. The replication topology
> is
> Transaction Replication with 1 queued updating subscriber. The
> distribution
> agent resides on the publisher.
> Firstly, I am aware of nosync replication, but my environment requires
> some
> more testing before I can implement it, because I can't take the publisher
> offline, and I believe some tweaks are needed to ensure that the data will
> truly be in sync. This said, one of my publications has a table article
> with
> 234 million records to transfer when the article is reinitialized. I am
> having problems with the transaction log growing so large on the
> subscriber,
> that it consumes all server space, and effectively kills the distribution
> agent.
> To mitigate this, I have tried to use the -BcpBatchSize parameter to try
> to
> get the rows per batch down to manageable size so that I can manually
> shrink
> the transaction log intermittantly while the distribution agent is
> applying
> the snapshot. My strategy is not working.
> Questions:
> 1) does -BcpBatchSize directly control the application of the snapshotted
> article's transaction commit size, or is this parameter used outside of
> the
> distribution agent's application of a snapshot?
> 2) does using -UseInprocLoader affect the -BcpBatchSize parameter? I ask
> because bulk insert is different from bcp.
> 3) would -CommitBatchSize be a more appropriate setting to allow me to
> actively manage the transaction log on the subscriber while this huge
> table
> is being transferred?
> Thanks for any input,
> John T
|||Hi Raymond, I though bcpBatchSize is analogous to the batchsize in bcp,
which means that it controls how many rows will be applied at a time in a
batch. Won't setting it to a large value create a very large transaction log
for large tables?
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:evddMLk8GHA.4084@.TK2MSFTNGP05.phx.gbl...
> If you are using concurrent snapshot on SQL2000, your only hope will be to
> make sure that you hit the minimal logging code path when the snapshot is
> delivered to the subscriber as the *entire* snapshot will be applied in an
> atomic transaction. At the risk of telling you something that you may know
> already, this means that you need to:
> 1) Make sure that 'select into\bulk copy' is enabled at the subscriber
> database
> 2) The target table is empty with at most one index or not having any
> indexes when the bulk copy occurs. This may be tricky to enforce as the
> SQL2000 index creation logic in the distribution agent is not very
> precise. You may want to modify the .idx scripts to leave only the primary
> key index and then manually create other indexes afterwards.
> 3) Set -BcpBatchSize to be *larger* than the maximum number of rows in
> your published tables. 2^31 - delta should work fine. Notice that you may
> start seeing "Agent is waiting for database backend.." messages since the
> distribution agent will not be able to log any progress messages until the
> entire bulk load operation is done. You have also want to increase
> the -QueryTimeout of the distribution agent.
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
>
|||Hilary, what you said is true, but the goal of my reccomendations is not to
have small transactions but to hit the minimal logging (or bulk-logged) code
path in the server which is the only feasible way to have a manageable log
size when a concurrent snapshot is applied in SQL2000. If a small batch size
is specified, the server will see the target table as non-empty after the
first batch is loaded and start going down the fully-logged code path after
that. And since there is an outer transaction bounding the delivery of a
concurrent snapshot in SQL2000, the log simply cannot be truncated even with
a small bcp batch size. I can understand why you think this is
counter-intuitive, but my suggestion had worked on a few occasions before
including the following:
http://groups.google.com/group/micro... e49f1fb79fe5
-Raymond
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uuGAtgk8GHA.2316@.TK2MSFTNGP04.phx.gbl...
> Hi Raymond, I though bcpBatchSize is analogous to the batchsize in bcp,
> which means that it controls how many rows will be applied at a time in a
> batch. Won't setting it to a large value create a very large transaction
> log for large tables?
> --
> 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
> "Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
> news:evddMLk8GHA.4084@.TK2MSFTNGP05.phx.gbl...
>
|||Ok, got it! Thanks Raymond. Still waiting on that beer you owe me;)
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:Oy1jKJl8GHA.2120@.TK2MSFTNGP03.phx.gbl...
> Hilary, what you said is true, but the goal of my reccomendations is not
> to have small transactions but to hit the minimal logging (or bulk-logged)
> code path in the server which is the only feasible way to have a
> manageable log size when a concurrent snapshot is applied in SQL2000. If a
> small batch size is specified, the server will see the target table as
> non-empty after the first batch is loaded and start going down the
> fully-logged code path after that. And since there is an outer transaction
> bounding the delivery of a concurrent snapshot in SQL2000, the log simply
> cannot be truncated even with a small bcp batch size. I can understand why
> you think this is counter-intuitive, but my suggestion had worked on a few
> occasions before including the following:
> http://groups.google.com/group/micro... e49f1fb79fe5
> -Raymond
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uuGAtgk8GHA.2316@.TK2MSFTNGP04.phx.gbl...
>
|||Raymond,
Just a couple of points of clarification:
1) If I am using simple recovery mode, I should get the same benefits in
this case as using bulk recovery mode, correct?
2) If I choose the schema option to drop the tables before the snapshot is
applied, this should meet all of the requirements in your second point,
correct?
3) Regarding the -BcpBatchSize setting of 2^31 - delta, what is the delta,
my desired batch commit size?
Thanks
John T
"Raymond Mak [MSFT]" wrote:
> If you are using concurrent snapshot on SQL2000, your only hope will be to
> make sure that you hit the minimal logging code path when the snapshot is
> delivered to the subscriber as the *entire* snapshot will be applied in an
> atomic transaction. At the risk of telling you something that you may know
> already, this means that you need to:
> 1) Make sure that 'select into\bulk copy' is enabled at the subscriber
> database
> 2) The target table is empty with at most one index or not having any
> indexes when the bulk copy occurs. This may be tricky to enforce as the
> SQL2000 index creation logic in the distribution agent is not very precise.
> You may want to modify the .idx scripts to leave only the primary key index
> and then manually create other indexes afterwards.
> 3) Set -BcpBatchSize to be *larger* than the maximum number of rows in your
> published tables. 2^31 - delta should work fine. Notice that you may start
> seeing "Agent is waiting for database backend.." messages since the
> distribution agent will not be able to log any progress messages until the
> entire bulk load operation is done. You have also want to increase
> the -QueryTimeout of the distribution agent.
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:469D5803-1C9E-447E-9513-2AE04EFEB305@.microsoft.com...
>
>
|||Hi John,
In response to your inquiry:
1) Simple recovery mode is fine.
2) You may still need to make sure that only the primary key index got
created since the index creation logic in SQL2000 distribution agent is not
as optimal as it can be.
3) Delta is just a small number, you only need to make sure that the
resulting bcpbatchsize is bigger than the maximum number of rows in any of
your tables
Hope that helps,
-Raymond
"John T" <JohnT@.discussions.microsoft.com> wrote in message
news:A677C2FE-F672-4473-9B2E-725AFE500039@.microsoft.com...[vbcol=seagreen]
> Raymond,
> Just a couple of points of clarification:
> 1) If I am using simple recovery mode, I should get the same benefits in
> this case as using bulk recovery mode, correct?
> 2) If I choose the schema option to drop the tables before the snapshot is
> applied, this should meet all of the requirements in your second point,
> correct?
> 3) Regarding the -BcpBatchSize setting of 2^31 - delta, what is the delta,
> my desired batch commit size?
> Thanks
> John T
> "Raymond Mak [MSFT]" wrote:
|||Wait a minute, I think you are the one who owe me a beer, and I have proof
for that...
http://groups.google.com/group/micro... c299fb7328e2d
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23yI5FQr8GHA.3820@.TK2MSFTNGP02.phx.gbl...
> Ok, got it! Thanks Raymond. Still waiting on that beer you owe me;)
> --
> 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
>
> "Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
> news:Oy1jKJl8GHA.2120@.TK2MSFTNGP03.phx.gbl...
>
|||freaking Google.
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
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:enfPtCt8GHA.1492@.TK2MSFTNGP02.phx.gbl...
> Wait a minute, I think you are the one who owe me a beer, and I have proof
> for that...
> http://groups.google.com/group/micro... c299fb7328e2d
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23yI5FQr8GHA.3820@.TK2MSFTNGP02.phx.gbl...
>
|||This suggestion worked excellently. I went from filling up over 275 gigs of
drive space trying to deploy these large tables, to only using 975 megs of
drive space.
Thank you,
John T
"Raymond Mak [MSFT]" wrote:
> Hi John,
> In response to your inquiry:
> 1) Simple recovery mode is fine.
> 2) You may still need to make sure that only the primary key index got
> created since the index creation logic in SQL2000 distribution agent is not
> as optimal as it can be.
> 3) Delta is just a small number, you only need to make sure that the
> resulting bcpbatchsize is bigger than the maximum number of rows in any of
> your tables
> Hope that helps,
> -Raymond
> "John T" <JohnT@.discussions.microsoft.com> wrote in message
> news:A677C2FE-F672-4473-9B2E-725AFE500039@.microsoft.com...
>
>
Distribution agent schedule
Hi,
1. I need to configure automatic stop of the distribution agent for
transactional replication and start in 3 hours in order guys could run their
reports on the replicated site. This means that distribution agent should run
all the time except the time 7.00-10.00, stop automatic at 7.00 and start at
10.00. How can I configure that through the schedule in the distribution
agent job settings (agent’s properties)?
2. What another solution could be suggested to run queries without
interrupting continuous work of distribution agent for transactional
replication (pull subscriber)?
1) Right click on your distribution agent, select agent properties,
schedules, and create a reoccurring daily schedule which starts at 10:00 and
stops at 7:00.
2) Have them look at Reporting Services or Analysis Services. These products
may be what they are looking for depending on their requirements.
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
"Elena" <Elena@.discussions.microsoft.com> wrote in message
news:7CFF7D5E-F884-4885-8459-6D396E644796@.microsoft.com...
> Hi,
> 1. I need to configure automatic stop of the distribution agent for
> transactional replication and start in 3 hours in order guys could run
> their
> reports on the replicated site. This means that distribution agent should
> run
> all the time except the time 7.00-10.00, stop automatic at 7.00 and start
> at
> 10.00. How can I configure that through the schedule in the distribution
> agent job settings (agent's properties)?
> 2. What another solution could be suggested to run queries without
> interrupting continuous work of distribution agent for transactional
> replication (pull subscriber)?
>
|||1) But what shall I choose in the hours option?
2) Reporting guys are already using Reporting Services. But not in the right
way I guess. Some Reports use multiple joins of huge tables.
"Hilary Cotter" wrote:
> 1) Right click on your distribution agent, select agent properties,
> schedules, and create a reoccurring daily schedule which starts at 10:00 and
> stops at 7:00.
> 2) Have them look at Reporting Services or Analysis Services. These products
> may be what they are looking for depending on their requirements.
> --
> 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
> "Elena" <Elena@.discussions.microsoft.com> wrote in message
> news:7CFF7D5E-F884-4885-8459-6D396E644796@.microsoft.com...
>
>
|||1) In the schedules table, select reoccurring. Click Change, Click daily,
and I'd select occurs every 5 minutes. With a start at 10:00 pm and stop at
7:00 am. Its not clear to me when you want it to start and stop. Can you use
am and pm or military times?
2) I can't comment if they are using it correctly or not. If you/they are
concerned about it, I would post to
microsoft.public.sqlserver.reportingservices
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
"Elena" <Elena@.discussions.microsoft.com> wrote in message
news:2950DC12-CE3B-48A7-B679-19872DD907C2@.microsoft.com...[vbcol=seagreen]
> 1) But what shall I choose in the hours option?
> 2) Reporting guys are already using Reporting Services. But not in the
> right
> way I guess. Some Reports use multiple joins of huge tables.
> "Hilary Cotter" wrote:
1. I need to configure automatic stop of the distribution agent for
transactional replication and start in 3 hours in order guys could run their
reports on the replicated site. This means that distribution agent should run
all the time except the time 7.00-10.00, stop automatic at 7.00 and start at
10.00. How can I configure that through the schedule in the distribution
agent job settings (agent’s properties)?
2. What another solution could be suggested to run queries without
interrupting continuous work of distribution agent for transactional
replication (pull subscriber)?
1) Right click on your distribution agent, select agent properties,
schedules, and create a reoccurring daily schedule which starts at 10:00 and
stops at 7:00.
2) Have them look at Reporting Services or Analysis Services. These products
may be what they are looking for depending on their requirements.
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
"Elena" <Elena@.discussions.microsoft.com> wrote in message
news:7CFF7D5E-F884-4885-8459-6D396E644796@.microsoft.com...
> Hi,
> 1. I need to configure automatic stop of the distribution agent for
> transactional replication and start in 3 hours in order guys could run
> their
> reports on the replicated site. This means that distribution agent should
> run
> all the time except the time 7.00-10.00, stop automatic at 7.00 and start
> at
> 10.00. How can I configure that through the schedule in the distribution
> agent job settings (agent's properties)?
> 2. What another solution could be suggested to run queries without
> interrupting continuous work of distribution agent for transactional
> replication (pull subscriber)?
>
|||1) But what shall I choose in the hours option?
2) Reporting guys are already using Reporting Services. But not in the right
way I guess. Some Reports use multiple joins of huge tables.
"Hilary Cotter" wrote:
> 1) Right click on your distribution agent, select agent properties,
> schedules, and create a reoccurring daily schedule which starts at 10:00 and
> stops at 7:00.
> 2) Have them look at Reporting Services or Analysis Services. These products
> may be what they are looking for depending on their requirements.
> --
> 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
> "Elena" <Elena@.discussions.microsoft.com> wrote in message
> news:7CFF7D5E-F884-4885-8459-6D396E644796@.microsoft.com...
>
>
|||1) In the schedules table, select reoccurring. Click Change, Click daily,
and I'd select occurs every 5 minutes. With a start at 10:00 pm and stop at
7:00 am. Its not clear to me when you want it to start and stop. Can you use
am and pm or military times?
2) I can't comment if they are using it correctly or not. If you/they are
concerned about it, I would post to
microsoft.public.sqlserver.reportingservices
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
"Elena" <Elena@.discussions.microsoft.com> wrote in message
news:2950DC12-CE3B-48A7-B679-19872DD907C2@.microsoft.com...[vbcol=seagreen]
> 1) But what shall I choose in the hours option?
> 2) Reporting guys are already using Reporting Services. But not in the
> right
> way I guess. Some Reports use multiple joins of huge tables.
> "Hilary Cotter" wrote:
Distribution Agent Process
Hi,
Our replication topology (currently in design) will use transactional
replication to replicate from a OLTP server (publisher) to a Reporting server
(subscriber) in hope of near realtime results. Not all of the tables require
this though and the plan would be to use snapshot replication once a day for
these less updated tables. We’re then going to use log shipping to ship
tranaction log files out to remote servers with the databases originating
from the Reporting server.
My question is what does the distribution agent do to the existing
subscriber tables when it applies the new snapshot files? I guess I’m
looking for information as to whether it TRUNCATES the table, DELETES the
data, or DROPS the table prior to importing the BCP files from the new
snapshot.
SQL 2005 SP1 exclusively will be used in this environment.
Any information would be appreciated.
It depends on what option you set in the article property.
The property you should look for is in the article property under the
destination objects and Action if name is in use
The options, are keep data, drop table, truncate and delete filter data.
"dgcull" <dgcull@.discussions.microsoft.com> wrote in message
news:4A2EAA92-0353-4E83-AAC0-546BD5E0C5B1@.microsoft.com...
> Hi,
> Our replication topology (currently in design) will use transactional
> replication to replicate from a OLTP server (publisher) to a Reporting
> server
> (subscriber) in hope of near realtime results. Not all of the tables
> require
> this though and the plan would be to use snapshot replication once a day
> for
> these less updated tables. We're then going to use log shipping to ship
> tranaction log files out to remote servers with the databases originating
> from the Reporting server.
> My question is what does the distribution agent do to the existing
> subscriber tables when it applies the new snapshot files? I guess I'm
> looking for information as to whether it TRUNCATES the table, DELETES the
> data, or DROPS the table prior to importing the BCP files from the new
> snapshot.
> SQL 2005 SP1 exclusively will be used in this environment.
> Any information would be appreciated.
>
|||Gopal is right, but just to add - the default is to drop the existing table
on the subscriber.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
Our replication topology (currently in design) will use transactional
replication to replicate from a OLTP server (publisher) to a Reporting server
(subscriber) in hope of near realtime results. Not all of the tables require
this though and the plan would be to use snapshot replication once a day for
these less updated tables. We’re then going to use log shipping to ship
tranaction log files out to remote servers with the databases originating
from the Reporting server.
My question is what does the distribution agent do to the existing
subscriber tables when it applies the new snapshot files? I guess I’m
looking for information as to whether it TRUNCATES the table, DELETES the
data, or DROPS the table prior to importing the BCP files from the new
snapshot.
SQL 2005 SP1 exclusively will be used in this environment.
Any information would be appreciated.
It depends on what option you set in the article property.
The property you should look for is in the article property under the
destination objects and Action if name is in use
The options, are keep data, drop table, truncate and delete filter data.
"dgcull" <dgcull@.discussions.microsoft.com> wrote in message
news:4A2EAA92-0353-4E83-AAC0-546BD5E0C5B1@.microsoft.com...
> Hi,
> Our replication topology (currently in design) will use transactional
> replication to replicate from a OLTP server (publisher) to a Reporting
> server
> (subscriber) in hope of near realtime results. Not all of the tables
> require
> this though and the plan would be to use snapshot replication once a day
> for
> these less updated tables. We're then going to use log shipping to ship
> tranaction log files out to remote servers with the databases originating
> from the Reporting server.
> My question is what does the distribution agent do to the existing
> subscriber tables when it applies the new snapshot files? I guess I'm
> looking for information as to whether it TRUNCATES the table, DELETES the
> data, or DROPS the table prior to importing the BCP files from the new
> snapshot.
> SQL 2005 SP1 exclusively will be used in this environment.
> Any information would be appreciated.
>
|||Gopal is right, but just to add - the default is to drop the existing table
on the subscriber.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
Distribution Agent often dies with the following message. Why?
Replication Distribution Agent often dies with the following log entry. At that hour little is ever going on so I am surprised that the error occurs.
Failed Job -> JobName: Instance1-DB1-Instance2-33, StepName: Run agent., Message: Timeout expired. NOTE: The step was retried the requested number of times (10) without succeeding. The step failed..
Any ideas where to start?
Thanks
1. Did you run Distribution Agent in a SQL Agent job? If Yes, can you try to run distrib.exe through command line?
2. Was Distributor/Publisher/Subscriber started when you run the distribution?
3. Do the SQL Agent job owner has the access right to Distributor/Publisher/Subscriber?
Thanks.
This posting is provided AS IS with no warranties, and confers no rights.
|||Yes, this runs as a Job and it runs normally most of the time so I assume the set-up is correct. It seems there is a transient issue that causes the issue. I just can't tell!|||Can you check the cleanup job schedule?
What is the retention setting?
This posting is provided AS IS with no warranties, and confers no rights.
|||From the "timeout" message, it is most likely a network/connectivity issue.Distribution Agent Latency question
I am delivering replicated data from a t3
connection to a t1 connection.. My ping times to
the subscriber are pretty good.. about 40ms
consistant. I have the following rates that seem
to be really slow for distributor/subscribers on
such good connections.
delivery rate (cmds/sec) = 212.0000
latency (msec) = 26890205 <--this seems high
# trans = 12
# cmds = 83784
avg. # cmds = 6982
This latency also seems to be making my
distribution database large on my distributor.
I am using default distribution agent profiles
and it's set to run every 15min.
I don't know - does 7 hours latency sound normal to you?
Latency is occasionally wrong. It reflects the delta between the time the
transaction entered the distribution database and the time it made it to the
subscriber.
If your distribution agent is not continuous the schedule is reflected in
the latency.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1be9951edb17d9149896d1@.news.newsreader.co m...
> I am delivering replicated data from a t3
> connection to a t1 connection.. My ping times to
> the subscriber are pretty good.. about 40ms
> consistant. I have the following rates that seem
> to be really slow for distributor/subscribers on
> such good connections.
> delivery rate (cmds/sec) = 212.0000
> latency (msec) = 26890205 <--this seems high
> # trans = 12
> # cmds = 83784
> avg. # cmds = 6982
> This latency also seems to be making my
> distribution database large on my distributor.
> I am using default distribution agent profiles
> and it's set to run every 15min.
|||In article <uEryCWJvEHA.3624
@.TK2MSFTNGP09.phx.gbl>, hilary.cotter@.gmail.com
says...
> I don't know - does 7 hours latency sound normal to you?
> Latency is occasionally wrong. It reflects the delta between the time the
> transaction entered the distribution database and the time it made it to the
> subscriber.
> If your distribution agent is not continuous the schedule is reflected in
> the latency.
>
Anything I should start looking at to resolve why
there is such high latency for this one
subscription only? I have the log reader set to
run continuous and the dist. agent to run every
15min.
tia
-comb
connection to a t1 connection.. My ping times to
the subscriber are pretty good.. about 40ms
consistant. I have the following rates that seem
to be really slow for distributor/subscribers on
such good connections.
delivery rate (cmds/sec) = 212.0000
latency (msec) = 26890205 <--this seems high
# trans = 12
# cmds = 83784
avg. # cmds = 6982
This latency also seems to be making my
distribution database large on my distributor.
I am using default distribution agent profiles
and it's set to run every 15min.
I don't know - does 7 hours latency sound normal to you?
Latency is occasionally wrong. It reflects the delta between the time the
transaction entered the distribution database and the time it made it to the
subscriber.
If your distribution agent is not continuous the schedule is reflected in
the latency.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1be9951edb17d9149896d1@.news.newsreader.co m...
> I am delivering replicated data from a t3
> connection to a t1 connection.. My ping times to
> the subscriber are pretty good.. about 40ms
> consistant. I have the following rates that seem
> to be really slow for distributor/subscribers on
> such good connections.
> delivery rate (cmds/sec) = 212.0000
> latency (msec) = 26890205 <--this seems high
> # trans = 12
> # cmds = 83784
> avg. # cmds = 6982
> This latency also seems to be making my
> distribution database large on my distributor.
> I am using default distribution agent profiles
> and it's set to run every 15min.
|||In article <uEryCWJvEHA.3624
@.TK2MSFTNGP09.phx.gbl>, hilary.cotter@.gmail.com
says...
> I don't know - does 7 hours latency sound normal to you?
> Latency is occasionally wrong. It reflects the delta between the time the
> transaction entered the distribution database and the time it made it to the
> subscriber.
> If your distribution agent is not continuous the schedule is reflected in
> the latency.
>
Anything I should start looking at to resolve why
there is such high latency for this one
subscription only? I have the log reader set to
run continuous and the dist. agent to run every
15min.
tia
-comb
Distribution Agent Issue
I have Transactional Replication set up in unidirection where subscribers are
getting read only data. Articles dont have any horizontal and vertical
partitioning either. The problem is even though there are transactions taking
place in Publisher, distribution agent is sitting idle and not replicating
any transactions. It is not throwing any errors either. Distribution agent is
just sitting idle and not replicating any data at all. This is really
strange. Any thoughts by anyone?
More information:
SQL 2000 EE SP3a on Windows 2003.
"Mark" wrote:
> I have Transactional Replication set up in unidirection where subscribers are
> getting read only data. Articles dont have any horizontal and vertical
> partitioning either. The problem is even though there are transactions taking
> place in Publisher, distribution agent is sitting idle and not replicating
> any transactions. It is not throwing any errors either. Distribution agent is
> just sitting idle and not replicating any data at all. This is really
> strange. Any thoughts by anyone?
>
|||Mark,
check to see if the job owner is a domain user, and if so please change to
sa.
Also check to see that the log reader agent has started and that
sp_browsereplcmds returns some rows.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Job owner is distributor_admin. Should I still change the owner to sa? And
yes, sp_browsereplcmds is returning data so I am not sure why distribution
agent is not pushing data.
I have second scenario where on another server Log Reader shows the status
as running but it doesnt read any transactions from the publisher's
transaction log. Any comments on this one?
Thanks in advance.
"Paul Ibison" wrote:
> Mark,
> check to see if the job owner is a domain user, and if so please change to
> sa.
> Also check to see that the log reader agent has started and that
> sp_browsereplcmds returns some rows.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Mark,
try changing the job owner to sa and restarting the job. Am not sure about
the other one at all unless the commands are part of a long-running
transaction?
Rgds,
Paul Ibison
getting read only data. Articles dont have any horizontal and vertical
partitioning either. The problem is even though there are transactions taking
place in Publisher, distribution agent is sitting idle and not replicating
any transactions. It is not throwing any errors either. Distribution agent is
just sitting idle and not replicating any data at all. This is really
strange. Any thoughts by anyone?
More information:
SQL 2000 EE SP3a on Windows 2003.
"Mark" wrote:
> I have Transactional Replication set up in unidirection where subscribers are
> getting read only data. Articles dont have any horizontal and vertical
> partitioning either. The problem is even though there are transactions taking
> place in Publisher, distribution agent is sitting idle and not replicating
> any transactions. It is not throwing any errors either. Distribution agent is
> just sitting idle and not replicating any data at all. This is really
> strange. Any thoughts by anyone?
>
|||Mark,
check to see if the job owner is a domain user, and if so please change to
sa.
Also check to see that the log reader agent has started and that
sp_browsereplcmds returns some rows.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
Job owner is distributor_admin. Should I still change the owner to sa? And
yes, sp_browsereplcmds is returning data so I am not sure why distribution
agent is not pushing data.
I have second scenario where on another server Log Reader shows the status
as running but it doesnt read any transactions from the publisher's
transaction log. Any comments on this one?
Thanks in advance.
"Paul Ibison" wrote:
> Mark,
> check to see if the job owner is a domain user, and if so please change to
> sa.
> Also check to see that the log reader agent has started and that
> sp_browsereplcmds returns some rows.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Mark,
try changing the job owner to sa and restarting the job. Am not sure about
the other one at all unless the commands are part of a long-running
transaction?
Rgds,
Paul Ibison
Distribution agent insufficient permissions
Hi,
I am trying implement replication and having problem when creating push subscription to an existing transactional replication publication.
The distribution agent is failing to run its job with the error:
Agent message code 14260. You do not have sufficient permission to run this command. Contact your system administrator.
I followed the http://msdn2.microsoft.com/en-us/library/ms151868.aspx article instructions when I set the distribution agent properties
What did I miss?
The following is the step error message:
Date 1/12/2007 2:30:01 PM
Log Job History (105342-DB3\PROD-MOMA-ArchivedTransactions-105337-DEV2-15)
Step ID 2
Server 105342-DB3\PROD
Job Name 105342-DB3\PROD-MOMA-ArchivedTransactions-105337-DEV2-15
Step Name Run agent.
Duration 00:00:00
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
2007-01-12 19:30:01.258 Microsoft SQL Server Replication Agent: distrib
2007-01-12 19:30:01.258
2007-01-12 19:30:01.258 The timestamps prepended to the output lines are expressed in terms of UTC time.
2007-01-12 19:30:01.258 User-specified agent parameter values:
-Subscriber 105337-DEV2
-SubscriberDB MOMA
-Publisher 105342-DB3\PROD
-Distributor 105342-DB3\PROD
-DistributorSecurityMode 1
-Publication ArchivedTransactions
-PublisherDB MOMA
-XJOBID 0x65C41EBC553D96439BAF69E4DC3CC823
-XJOBNAME 105342-DB3\PROD-MOMA-ArchivedTransactions-105337-DEV2-15
-XSTEPID 2
-XSUBSYSTEM Distribution
-XSERVER 105342-DB3\PROD
-XCMDLINE 0
-XCancelEventHandle 00000000000006E8
2007-01-12 19:30:01.258 Startup Delay: 214 (msecs)
2007-01-12 19:30:01.477 Connecting to Distributor '105342-DB3\PROD'
2007-01-12 19:30:01.618 Agent message code 14260. You do not have sufficient permission to run this command. Contact your system administrator.
Can you verify the following?
Distribution Agent for a push subscription
The Windows account under which the agent runs is used when it makes connections to the Distributor. This account must:
At minimum be a member of the db_owner fixed database role in the distribution database.
Be a member of the PAL.
Have read permissions on the snapshot share.
Have read permissions on the installation directory of the OLE DB provider for the Subscriber if the subscription is for a non-SQL Server Subscriber.
|||Hi Gray,
Thank you for interesting in my problem.
As I wrote is my first post, I set all required settings ti the distributor Windows account:
it is db_owner of the distribution database|||
Hi Igor,
This error message should not be related to running executables. It is more like SQL permission issue. I would try to turn on SQL profiler to trace the statement in replication SPs. Then we can find out where the 14260 error message is thrown.
Thanks,
Peng
|||Hi Peng,Thank you for interesting on my problem. It really was related to the SQL rights. Actually, whe I added the distributor user to the db_owner role on the distribution database, the subscription started working properly.
Thank you,
Igor
Subscribe to:
Posts (Atom)