ntfrs.jdb growing too big

  • Thread starter Thread starter Fari Fuladi
  • Start date Start date
F

Fari Fuladi

I have had a couple of cases where the size of ntfrs.jdb
file grew to a few gigs. I don't know what can cause the
size of this file to grow so big. I have had a few cases
of unstable Dfs and ntfrs services which may have
contributed to its gigantic size, but am not too sure
about that either. So, a few of questions that comes to my
mind:
- What can cause ntfrs.jdb file size to grow so big?
- ntfrs.jdb stores the replication transactions. What's
the relationship between the number of file replication
that takes place and size of this file? Any dependence on
the size of the file? Probably a high dependence on the
number of files being replicated. Right?
- Does the file ever shrink? Or, it keeps on growing until
it gets to a point that there is no more disk space upon
which ntFrs will terminate. Is this assumption correct?
- Do I need to clean up this file on a regular basis to
stop it from growing too big?

A whole bunch of other questions that may come up later.
But, in the meantime, I'll appreciate if you could share
your thoughts this issues.

thanks,

Fari
 
Hello Fari,

The NTFRS.JDB file is a Jet Database file that resides by default in the
following location: --> %systemroot%\Ntfrs\Jet\Ntfrs.jdb

This file stores the results of FRS transactions to include the following
elements in each replica set for every server participating in the FRS
replication topology:

Connection Table
Inbound Log
Outbound.log
Version vector
ID table

Notice that the Outbound Log can become quite large, particularly any links
are down or slow, large number of changes occur, or the replication hours
are restricted.

Also notice that the NTFRS.JDB file is distinct in both location and
purpose from the NTFS Change Journal.

One way to reduce the size of this file is to do a "non-authoritative"
restore of the database file from the other controllers participating in
the domain replication topology.

You will first need to ensure that the data in the SYSVOL folder of the
other servers is up-to-date and correct.

"Non-authoritative" restores are accomplished by setting the "BurFlag"
registry key to "d2".
For more information on the BurFlag keys, please see:

FRS: Using the BurFlags Registry Key to Reinitialize File Replication ID:
290762.KB.EN-US
http://support.microsoft.com/?id=290762

Thank You.

Diana.



(e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top