Can't start transactional replication SQL 2005. System.OutOfMemory Exception during start

We currently use log shipping to 2 other servers for reporting. We
want to use transactional replication instead, so that our reporting
databases are always available (when the restore agent runs the
database is unavailable for a few seconds) and to reduce the latency
between changes in the main database appearing in our reporting
database.
I've successfully got replication to work on a test scenario (with
only a few thousand rows) but when I try and get transactional
replication going on our production site I get a System.OutOfMemory
exception when performing the snapshot. It fails at about 40 percent
of one of our larger tables (157 million rows.) The database backup
is about 27GB.
The hardware has 4GB memory, 2 dual core x86 running 32bit Windows
Server 2003.
We are running SQL2005 Standard edtion SP2, but I had the same problem
on SP1.
I've tried the /3GB switch.
I've tried putting the distrubutor on the main server, and on a
seperate server, and on the reporting box.
I've tried pull and push subscriptions.
I'm going to try a row filter to pull only the most recent data (to
drop the number of rows) and see at what point it fails, but this is a
fairly long interative process. And we do need all the data in the
end.
I'm looking for advice, has anybody else had similar problems?
Is there a way to start replication from a restored database?
I'm considering installing more Memory - but am unsure how to estimate
how much more memory we need. Also our machines run fine with 4GB of
memory normally; I can't really afford to buy more memory just to
"start" the replication process going (but of course I guess this
depends on how much more I would need!)
Daniel Bryars
This is something that I would really like to have a closer look so let me
ask you a few questions:
1) Is snapshot.exe consuming a large amount of memory according to taskmgr?
2) Do you have a pagefile configured on the distributor machine? I have
heard of one case where disabling the pagefile seemed to be the cause of OOM
error in the snapshot agent. I suspect that this may have something to do
with the use of memory mapped file in the underlying BCP api but I was never
able to prove one way or another.
3) Do you have a large amount of blob column data?
If possible, you may also want to consider upgrading your software stack at
your distributor (OS + SQL Server) to 64bit as it is quite possible that you
are running out of address space range. Most dual-core processors should
already be capable of running in 64bit mode.
-Raymond
<bryars@.hotmail.com> wrote in message
news:1174821642.773195.15500@.e65g2000hsc.googlegro ups.com...
> We currently use log shipping to 2 other servers for reporting. We
> want to use transactional replication instead, so that our reporting
> databases are always available (when the restore agent runs the
> database is unavailable for a few seconds) and to reduce the latency
> between changes in the main database appearing in our reporting
> database.
> I've successfully got replication to work on a test scenario (with
> only a few thousand rows) but when I try and get transactional
> replication going on our production site I get a System.OutOfMemory
> exception when performing the snapshot. It fails at about 40 percent
> of one of our larger tables (157 million rows.) The database backup
> is about 27GB.
> The hardware has 4GB memory, 2 dual core x86 running 32bit Windows
> Server 2003.
> We are running SQL2005 Standard edtion SP2, but I had the same problem
> on SP1.
> I've tried the /3GB switch.
> I've tried putting the distrubutor on the main server, and on a
> seperate server, and on the reporting box.
> I've tried pull and push subscriptions.
> I'm going to try a row filter to pull only the most recent data (to
> drop the number of rows) and see at what point it fails, but this is a
> fairly long interative process. And we do need all the data in the
> end.
> I'm looking for advice, has anybody else had similar problems?
> Is there a way to start replication from a restored database?
> I'm considering installing more Memory - but am unsure how to estimate
> how much more memory we need. Also our machines run fine with 4GB of
> memory normally; I can't really afford to buy more memory just to
> "start" the replication process going (but of course I guess this
> depends on how much more I would need!)
> Daniel Bryars
>

Can't shrink transaction log

Instead of shrinking it, back it up first, this should get
rid of the active parts of the log file, then shrink it.
Peter

>--Original Message--
>Hi,
>A SQL Server2000 database we have has ended up with a
>massive Transaction Log (basically because the
maintenance
>schedule needs looking at).
>Anyway to cut a long story short, I backed up the
>transaction log which truncated it, but I can't seem to
>shrink the logfile to free up the space.
>I tried:
>DBCC SHRINKFILE (2, 200, TRUNCATEONLY)
>[where 2 is the filenumber of the logfile]
>This came back with:
>'Cannot shrink log file 2 (Main_Log) because all logical
>log files are in use.'
>Can anyone tell me how I can shrink this log file please?
>Regards,
>Vince
>.
>Check this article out
Shrinking the Transaction Log in SQL Server 2000 with DBCC
http://support.microsoft.com/?id=272318
Regards,
Gayathri Rau [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.