This is on collecting Replicate
process dumps
so if you get a Replicate task that's
ending abnormally
or generating dumps this is what this
presentation is about
okay so some of the things we're going
to cover things to set up and Replicate
if you're running on Windows, Linux
after you create the dumps what you're
going to need to gather
to provide to r d the first thing we
want to do
is in Replicate so one of the first
things you can do is set the maximum
recreate count to one
so this will stop the tasks from
restarting over and over and over again
creating huge log files all right so
usually i just set the maximum recurrent
count to one we also want to have
verbose logging
so if the task is bending right after
you start it
set verbose logging to verbose on
everything
so we don't have to go back and forth
trying to figure out what we want
there's a check box about storing
tracing for most logging in memory
and then if an error happens it'll then
write that information to disk
the problem is that's not going to work
for a crash
so we want to make sure that that's
unchecked that memory setting
only outputs that information if an
error is encountered if the crash
happens before the error gets back from
say an odbc driver
back to the task the tas is not going to
know about it because the test is
crashed
so we want to make sure you uncheck that
memory setting
so that's the Replicate side pretty
simple
just set verbose logging for everything
on the Windows setup
so we want to install a product from
microsoft called debug diag
so this is a way to capture those dumps
in the Windows environment so you
download it from Microsoft
install it on the server so it's
it's pretty standard microsoft utility
we're going to add a cache rule so when
you install it
and add a rule first thing you see is
the rule type
so we want to select crash and next
you want to do it for a specific process
and then you're going to put in the
selected process you're just going to
put in the executable name or Replicate
so it's repctl.exe
so just type in that value and hit next
on the advanced configuration option you
want to
capture a full user dump you don't want
to do
it defaults to 10 you can leave it at 10
but
we don't need that many dumps we just
need the first and second exception so
usually i just set that value to a two
and that's the maximum number of dumps
created by the rule is two
and then you give it a location give it
a place that
has plenty of disk space these crash
dumps can be
quite large sometimes and then
activate the rule now you can also
create the rule without activating it
right now if you're just setting this up
and not running it yet so after you do
that you should see a screen that looks
like this
the state is going to show as active
after the crash runs and captures those
dumps you'll see it as completed
if you need to do it again you need to
highlight this
and reactivate the rule so that it's in
in force again but when it's in a
completed state it's not going to
capture any more
dumps so on the Linux side first you
need to check to see if the core dump's
enabled and you can do that with a
limit command so when you first run you
limit if it's not set you'll see
in here it'll say file size 0 that means
it's not
enabled so if you uh then set it
you can do this you limit dash c
unlimited uh you'll then see
that it's set to unlimited instead of
zero you can then
look and see where the location of where
the dumps gonna go so you can
cat on this core pattern you can also
change that core pattern and i suggest
you use
include the percent sign p when when you
do it so that the pit will be part of
the name so it's easy to match up later
this is pretty well documented in Linux
documentation of
all the parameters that you can pass to
this coordinate file naming
so let's say that we've turned on the
dump
capturing we have a dump so Replicate's
task is run and it's amended so what do
we want to gather
to provide to r d so typical
Replicate things tax diagnostic package
the full Replicate task log and i put a
note on here
when you run and capture a diagnostic
package it will only get the first five
meg and last five made
from my task log so because we turned on
verbose on everything
that log can be you know hundreds of may
so make sure that you get the log
directly from
the logs directory to provide to rnb
so that's very important on this on the
Windows we want both the first and
second chance
exception dump files so they there's
quite a few files created
uh this is log.txt files process lists
all of these what rd is looking for is
just the dump files the first and second
chance exception files
it's also very important to get the ones
that match up
with the pid so in a task log
the very first line will show what pit
it was running as
make sure that you get the same pid for
the first and second chance exceptions
that way they already knows that they
match up with the log they're looking at
on Linux very similar the task log is
going to show the pin
and if you use the percent sign p in
the core dump name then you'll see that
as part of the quarter note file
on the Linux side you only get a single
dump you won't get like a first and
second exception you just have one
quart file so other things to
gather around the environment typically
most of our crashes are caused by a
driver file
a database driver file an odbc file so
you want to make sure we gather
the source and target driver versions
ask them if they're
updated anything recently did they just
update an odbc driver
did they do other change to the owc
ini file on Linux did they install
another driver
it's not related to Replicate things
like that so we want to know about
the environment as far as the drivers
and what's installed
uh server specifications so is this
what version of Windows, what version of
Linux
exact version down to the very lowest
detail that we can provide in rmd
um maybe some information about the
workload does the crash only happen
when the task is very busy or conversely
does it happen only when it's very slow
middle of the night there's no activity
on the source that's when the crash
occurs
busy or slow can sometimes lead a clue
to uh for rme does the operating system
change was it patched
on wednesday nights when microsoft
pushes out fixes did it then start
crashing after that
is it reproducible a lot of times r d is
getting this dump file
and a log don't really know what caused
the problem
now they're gonna go into the dump
they're going to look at the source code
they're going to try to figure out what
caused it
but if it's reproducible it helps r d to
fix the problem faster
so if it is reproducible let's get
detailed steps
create a task with this source endpoint
run this type of transaction through
any detailed steps that you can provide
is good
source related so if i create a dump and
the last thing in my task log is
something related to the source
source capture source unload something
like that
it might be related to the transaction
log
Replicate ran across something that it
couldn't parse or something to that
effect
the customer can provide the database
transaction logs let's ask for them then
sometimes you know transaction loans
roll off and i can't get to them
so if we can provide them let's grab
them so that was the
that was everything uh thanks for
joining
thanks everyone have a good day
.png "Former Employee"){kind=icon}
