Replication and AI. Offline clearing of AI Files. - Forum - OpenEdge RDBMS - Progress Community

Replication and AI. Offline clearing of AI Files.

 Forum

Replication and AI. Offline clearing of AI Files.

This question is not answered

I have a database that writes a lot of data to AI and this is code related as we know about this. This morning we had the issue where the DB went into stall because the /aibackup area where we write the full AI's out was full. We have a restart on the DB daily at 05:00 and when the DB was shut down we were unable to start it. We cleared the AI Backup area and tried restarting the DB. This did not work. We then disabled replication and AI  and re-enabled AI and replication.We busy with a backup so that we can sync the replicated DB's. We have 2 targets on this DB.

The Question is as follows:

Is there a command to run to clear the full AI files before trying to start the DB after a stall.?

All Replies
  • As far as I know, if the DB is down because the AI is full, all you can do is what you did do.

    But you really should be monitoring AI and the -pica buffer if you're running Replication. And I mean REALLY! As your database grows, reseeding Replication will get harder and harder, and of course you lose the benefit of Replication while it's not running. What happens if something breaks when it's not running?

    Take a look at ProTop. It is able to monitor your AI and your pica, and many other things, and will alert you BEFORE a problem happens so you can fix it. Prevention is definitely better than a cure.

  • Ahmed,

    When you say "ai backup area" do you mean the directory that the ai management daemon copies full extents to?

    If so, then I believe that you need to restart aimgt after freeing up that space.  It does not notice the free space without a kick in the pants.

    rfutil dbname -C aiarchiver end

    # free up disk space

    rfutil dbname -C aiarchiver enable

    You could also send the ai files to an alternate directory with the "setdir" option.

    --
    Tom Bascom
    tom@wss.com