-
Originally posted by Mr.Hanky
You can drop them, sure. But frankly 1.7 is a small database so why bother? I don't think you will save a lot of time
Did you? I thought you would save ZERO time
-
The trouble with export/import of indexes is that the creation on import is done in a serial fashion, which can be very sow and leave idle resources on the target daatbase.
If you export including indexes, then import with indexfile=y, you can get the DDL for the indexes from the dump file and work out a way of submitting multiple index create statements at the same time
-
So, am I to gather then from all of your comments that even dropping the indexes completely saves no time either? I understand that indexes are built at import time based on the ddl. However, I guess I need to dig more into the storage of indexes. I was of the understanding that when you create an index, that index is stored somewhere. Thus, that is data in and of itself that gets exported. True?
For example, I have a auditing table that my app uses to track user actions. It has about 15million rows in it and 9 columns. 5 of those 9 are indexed. Thats a ton of index data that is being stored in a tablespace we have set aside just for storage of this table's indexes.
Does that data get exported? Or is it ignored at export? That is what I am going to test next. I am going to drop those indexes on that table in my test box and do an export.
Thanks for all the great feedback. The learning just never stops!!
-
Just because something is physically stored in the database does not mean it will be stored within an export file in the same manner. The export file stores all of the ddl commands to create all of the objects in the database and the data stored in a binary form. The exception is that when you export as system you are not exporting things owned by sys. Which is probably a good thing. You are importing into a database that has a data dictionary.
So if you really want to save time on the import. Do an import with indexes=n. and have all of the ddl you need for creating the indexes. If you could have a shell script or two that will submit more than one create index at a time then the creation of the indexes might go faster depending on your hardware and operating system as well as the init parameters of the target database. However, if you have good hardware and all of the relevant server os patches this should go quickly. If it doesn't you can always buy more ram.
-
I guess at this point we should start talking about setting SORT_AREA_SIZE and the possibility of parallel index creates.
MH
I remember when this place was cool.
-
Nope, my hardware is not an issue. Plenty of ram, cpu, etc to do the job. Import is not my real area of concern.
My goal is to minimize the export time of the database. I don't want to be sitting around for 90 mins waiting for the export if I could have got it done in 45 by manipulating the export. Our vendor, who designed both the app and the database, has told me that he plans to drop a dozen of the largest indexes in the system before exporting. He claims this will reduce the export time of the database by a fair amount. I am attempting to prove/disprove this area.
Now, I understand that within the export file the DDL is seperate from the data. This allows you the option of Rows=N so that you can just rebuild the objects themselves. But, with regards to the index itself, what I gather from your inputs is that even though that index is occupying physical space within my database, it is not exported. Only the index definintion (DDL) gets exported. Thus, on import, the index is created.
Have I got it now? If all this is true, then there appears to be little that I can do to speed up the full export other than having all users log off so that Oracle has the machines full CPU and other resources to do the export.
-
By George I think he's got it.
I think the only parameter that will speed up your export is DIRECT, but you have to decide if you want to use it or not. I hope you bet the guy and win something nice.
Ps. ROWS=N will speed it up too
MH
I remember when this place was cool.
-
Originally posted by DcsoBob
Nope, my hardware is not an issue. Plenty of ram, cpu, etc to do the job. Import is not my real area of concern.
My goal is to minimize the export time of the database. I don't want to be sitting around for 90 mins waiting for the export if I could have got it done in 45 by manipulating the export. Our vendor, who designed both the app and the database, has told me that he plans to drop a dozen of the largest indexes in the system before exporting. He claims this will reduce the export time of the database by a fair amount. I am attempting to prove/disprove this area.
As you've already experienced, and people have already responed, dropping indexes before an export will not speed up the export process significantly. When Oracle exports your database, it exports the data along with the table, but not with the index. The only thing the .dmp file knows is how to rebuild the index. (Which, by the way, it sometimes does wrong.)
Your consultant may be suggesting to drop the indexes before the export to help speed up the import. Maybe he is planning on rebuilding indexes in parallel once the data is already in the database.
Now, I understand that within the export file the DDL is seperate from the data. This allows you the option of Rows=N so that you can just rebuild the objects themselves. But, with regards to the index itself, what I gather from your inputs is that even though that index is occupying physical space within my database, it is not exported. Only the index definintion (DDL) gets exported. Thus, on import, the index is created.
By george, I think he's got it.
Have I got it now? If all this is true, then there appears to be little that I can do to speed up the full export other than having all users log off so that Oracle has the machines full CPU and other resources to do the export.
Have you played around with:
1. BUFFER size (which there is a bug in big buffers)
2. DIRECT=Y
3. Placing your .dmp file on stripped disk
4. Parallel exports by schema
Personally, I think export/import for migration purposes is a waste of time. I think you should clone your database from the old box to the new box & use ODMA to migrate it. It will be 50 times faster and you won't have to worry about silly options like COMPRESS=N, CONSISTENT=Y, FOO=bar, etc.
And you've stopped using export/import for backup, right?
Jeff Hunter
-
Originally posted by Mr.Hanky
By George I think he's got it.
Now I'm really scared. I'm thinking like Mr.H... (or is Mr.H thinking like me....)
Jeff Hunter
-
Sorry Jeff, as the timestamp indicates I beat you by 2 minutes, you must be slowing down.
Maybe it was my double expresso!!
MH
I remember when this place was cool.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|