ciatecmx
3rd August 2006, 17:43
our set up is a BAAN V with Oracle 10g r2 on an AIX 5.3 box. Somehow one of our experienced BAAN admin think that because of the propriety SQL sscripts by BAAN, the oracle flashback (recovery) set up will not work well with BAAN. Is that true? any expierenced user, please toast your advanced thoughts. Thanks.

patvdv
3rd August 2006, 18:14
Please post your question in the proper forum next time!

Markus Schmitz
4th August 2006, 09:36
There are no Baan properitary scripts. Actually Baan is using Oracle on a very basic level and is not even using features, like stored procedures, triggers or counters.

So Flashback should work.

Regards

markus

Dikkie Dik
4th August 2006, 10:10
I am for 99% sure that Flashback works with Baan. But never try to combine db results you stored outside that database like auditing files.

Kind regards,
Dick

pastipet
9th August 2006, 14:19
Term FLAHBACK refers to several different several different technologies in Oracle 10G R2. In my opinion some of these are safe with Baan while using others should be carefully considered.

1. Flashback database
This is should be safe because it is equal to restoring the whole database to a earlier point of time. All your data should be consistent after this operation.

2. Flashback table
This option is obviously more dangerous. Oracle has no way to determine which Baan tables would dependent on the table being flashed back. Same goes for flashing back dropped tables. This way you always risk inconsistencies in your data.

Of course you can always start with comparing current data with the data you want to flashback using flashback queries. And how far back in time you can go depends on Oracle parameters UNDO_RETENTION, DB_RECOVERY_AREA_SIZE, DB_FLASHBACK_RETENTION_TARGET

BR:
Petteri

Kozure Ohashi
9th August 2006, 23:17
One possible usage:

(1) Somebody deleted or modified e.g. the tiitm001
(2) Admin gets information very quickly -> restrict usage of your baan server
(3) use flashback sql like:

sql> create table itm001temp as select * from baan.ttiitm001100 as of timestamp "date/time before modification"

advantage:

Inserting the values in an other table you don't need to activate "row movement" parameter for the original baan table.

Result: Now you have a "backup" of your data before modification without a whole recovery scenario.

As other mentioned you need to know what you are doing (dependencies are not restored!), a possible good solution for mastertables.

Works since 9i.

Regards,

Kozure

ciatecmx
11th August 2006, 21:32
Thanks Pastipet. As I understand the Oracle Flashback part of document. If it only flashback part of data of a table, it seems there is no risk. However, if it is to flashback a drop table, apparently I need to worry about the dependencies of the original table in the scope of BAAN. Is that because when BAAN issued the drop of a table, it also changed the definition of the sturcture of the company which the table belonged? and if oracle restores the table, there is no way that oracle restores that relationship (or comapny definition)? Is that right?

Kozure Ohashi
12th August 2006, 00:56
In my understanding no, "normaly" you drop a table "wrongly" with baan tools "delete table" or with oracle sql command drop table. The problem is e.g. you write log data from another table. Then you drop the log table wrongly, the master table is still in use e.g. for one day having 1000 records more. If the script is programmed in a way that you get no error if the insert or update in the log table fails, and now you flashback the dropped table from the recycle bin you are missing the log info for the 1000 records.

If you drop e.g. the tiitm001 (Item Master) you normaly recive an error if a script tries to acces the table, therefore you can not work with the baan system.

Be aware that if you use "sql>drop table <table_name> purge" you can not flashback the table from the recycle bin!
Another problem could be if you already created a table with the same table name e.g. with baan tools, you also can not flashback this table anymore.

I think no, the table definition (and relation) is not affected by a drop of the table. If you restore the dropped table using flashback maybe you have to create the index with baan session "reorg tables" -> Data and Indices, because you can only flashback a table from the recycle bin of oracle.

There are always to sides:
(1) Baan Table definition, constraints and relations (in the Data Dictonary)
(2) The table itself with the data on oracle level (with index).

Regards,

Kozure