Subject Re: Disable / Enable Triggers
Author Adam
--- In, "t.s." <truesaint@...> wrote:
> Dear all,
> The following list contains the steps necessary when upgrading a
> production database:

That is a bold assertion.

> 1. backup old database.
> 2. export old generator values.
> 3. export old data (as INSERT statements).
> 4. create new empty database (with triggers, views, sp, etc).
> (or provide a fresh, empty copy of the new FDB)
> 5. import old generator values.
> 6. import old data.
> 7. finished.
> In a database with larger data and complex trigger processing,
step#6 is
> taking a lot of time since the triggers are already active at that
> Is there a way to disable all triggers before doing step#6 ?
> (and of course, re-enabling them afterwards).
> Thanks in advance,
> t.s.
> PS: Or, if anyone has a simpler/better/faster idea on how to 'upgrade a
> production database', i'm all ears. Thanks.

I'm with Alan here. I have never used such a complex procedure and
upgrades are not a problem for us.

Here is mine.

1) Make sure no-one is using it, rename the database to prove it.
2) Take a file copy of the database just in case. (The server can't
see the file because it is renamed so it can be safely copied).
3) Run your upgrade DDL.
4) Run a backup of the 'upgraded' database with -g option.
5) Restore the backup file from step 4 (rebalances everything)
6) Rename the restored database in 5 so the alias points to it again.
7) Finished

If you do encounter any problems, you always have the backup in step 2
to fall back on.

When writing a DDL script. Whenever in your DDL script you perform any
DML, consider the fact you have triggers and indices that are being
updated, and consider whether it would be beneficial to temporarily
disable them.