Is it needed to consider hidden files while performing dump

Don't do a dump and load through the data dictionary. It will be very slow. Use the dictionary for the df, but do a binary dump and load for the data. And make sure you're on a modern version of Progress (11.x, or 10.2B08 at a push) as there are a lot of efficiency gains to leverage.

But to answer your question you don't need to dump hidden files.

Hi James ,

Thanks for your quick reply. The databse size is aroung 15 GB , so thought of perfroming dump and load through data dictionary.

Yes , we are moving to 11.5 version.

As you mentioned , it is not required to dump hidden files. just want to know why hidden files are meant for.Please provide me suggestion on this,

The hidden files are the VSTs (Virtual System Tables) that Progress maintains to run the database. You don't need to worry about them.

What is the reason for the dump and load?

There are other things you may need to dump and load

* user defintions

* sequence current values

* sql permissions if odbc/jdbc is in use

* sql views

some of those are in the hidden files but have there own dump & load procedure.

I couldn't find a complete list on the PKB but there are various articles on the individual items you may need to dump & load.

Thanks James .

The reason for dump and load process is 'we are migrating database from OE 10.1C to OE 11.5 ' and 10.1C database are in hp-ux os and OE 11.5 database are going to be in Linux cent 6.5 OS .

Since it is both progress as well as hardware upgradation , proresting database backup image (10.1C database) got failed in Linux cent os 6.5 where OE 11.5 is running.

So i created database in linux cent os 6.5 where OE 11.5 is running in following way.

1. Prostrct create <db-name> db-name.st -blocksize 8192.

2.procopy /usr/dlc115/empty8 <db-name>.

3.Took .df and .d files from OE 10.1C and loaded into linux cent os where 11.5 OE is running through data dictionary.

Please just verify my steps , let me know if anything is missing out.

Is there any other method to create database in my above mentioned scenario.

TIA,

Vithal Kattikar.

I'm not an expert in *nix stuff, so you may want to await other inputs, but AFAIK if you're migrating across *nix versions then you want to be very careful with using a dump and load from the dictionary. A binary dump and load is safer in terms of integrity of your data. Like I say I could be very wrong.

Nevertheless, a binary dump and load will be much easier to achieve as you can automate it very easily.

In terms of your steps then your process looks fine.

Note cverbiest's comment about sequence values. If you use the sequences in Progress then this is a necessary step as they will initialise to an invalid value otherwise and you'll either get corrupt data or errors (depending on how you validate things).

Hi cverbiest,

In above thread , James mentioned that no need to worry about hidden files.I

please let me know how we can dump and load users definations , sequence current values,sql permissions if odbc/jdbc is in use and sql views.

TIA,

VK

All the things mentioned are options in the data dictionary, but you only need to worry about doing the steps if they are facilities you use.

Thanks James ,

I assume that step 1 and step 2 are correct . In step 3 , insted of performing in dump and load , it is good to perform binary dump and load.Please correct me if I understood something  wrong.

Yes cverbiest's suggested to load other stuffs also individually , one question here if I perform binary dump and load , is

it necessary to load other stuffs like users defination , sequence current values , sql permision , sql views seperately .

second thing is like how do I know binary dump and load is successfull.

Below is my program for performing binary dump and load.

define var vdb as char format "X(10)" no-undo.

update vdb.

output to value("dump" + vdb + ".sh").

for each _file  no-lock:

 put unformatted "proutil " + vdb + " -C dump " + _file-name + " /u2/tsmpdump/ " skip.

 end.

 output close.

 output to value("load" + vdb + ".sh").

 put unformatted "proutil " + vdb + " -C truncate bi -G 0 -biblocksize 32 -bi 65536" skip

 "proserve " + vdb + " -B 20000 -spin 20000 -bibufs 300" skip

 "probiw " + vdb skip

 "proapw " + vdb skip

 "proapw " + vdb skip.

 for each _file  no-lock:

   put unformatted "proutil " + vdb + " -C load /u2/tsmpdump/" + _file-name + ".bd " skip.

   end.

   put unformatted "proshut " + vdb + " -by" skip

   "proutil " + vdb + " -C idxbuild all -TB 32 -TM 32" skip

   "proutil " + vdb + " -C truncate bi -G 0 -biblocksize 16 -bi 32768" skip.

   output close.

Hi Vithal,

These are listed in various Progress Knowledge base entries. My list is not complete, I just wanted to give you the idea there may be more things to consider.

Some links,

knowledgebase.progress.com/.../P111448

knowledgebase.progress.com/.../P82003

knowledgebase.progress.com/pkb_Home

Yes if you do a binary D&L the other stuff still needs doing as a separate job.

As several people have pointed out "it depends".

Some vendor supplied systems have hidden tables of their own.  This is usually related to licensing or other protection schemes.  Those are not "system" tables and they do need to be dumped and reloaded.

Thank you All ,

From all above threads ,i understood that just to be on safer side , it is good to D&L hidden files.

Apart from this , we also need to dump and load the below stuffs also.

* user defintions

* sequence current values

* sql permissions if odbc/jdbc is in use

* sql views

*security permission

*Security authentication records.

please let me know if anything is missed out.

TIA,

Vithal Kattikar.

No.

It is not "safer" to do all of these things "just in case".

You need to understand which of these possible options are actually needed for your particular situation.  You probably do not need all of them.

Depending on what you are doing and why some of them can actively damage the success of a dump & load.  In particular dumping all hidden files is almost always a bad idea.  Dumping selected hidden files that a specific application requires *might* be necessary -- but it might also be problematic.  When an application uses hidden files the designer is probably implementing some sort of licensing or copy protection schema and there is a good chance that you need to work with the supplier of that application to successfully manage the creation of a new instance of the db.