Question DUMP AND LOAD?????? TIME COSUMING
- Thread starter Mike
- Start date
Rob Fitzpatrick
ProgressTalk.com Sponsor
Hi Mike,
First, please don't use all capital letters in posts or thread titles. It looks like you're shouting. Please talk, don't shout.
Second, please re-read your post and ask yourself how much information you have provided us about your situation. It isn't much. The more we know, the more we can help. Please read this thread and use its advice as the basis for your next post.
Third, it sounds like you're saying you have ten tables that are each 500 GB in size. That's 5 TB. Is your database really that large? If it is, you should expect a somewhat time-consuming dump and load. Of course, without any specifics at all, we don't know how time-consuming it is or whether it is longer than it should be or could be.
Please read the thread I linked to and provide some details about your situation. Thanks.
First, please don't use all capital letters in posts or thread titles. It looks like you're shouting. Please talk, don't shout.
Second, please re-read your post and ask yourself how much information you have provided us about your situation. It isn't much. The more we know, the more we can help. Please read this thread and use its advice as the basis for your next post.
Third, it sounds like you're saying you have ten tables that are each 500 GB in size. That's 5 TB. Is your database really that large? If it is, you should expect a somewhat time-consuming dump and load. Of course, without any specifics at all, we don't know how time-consuming it is or whether it is longer than it should be or could be.
Please read the thread I linked to and provide some details about your situation. Thanks.
The fastest way to dump and load is using binary dump/load (table by table, and concurrently), then Index Build.
But if it's a matter of time, why not considering the problem from another point of view: If your DB has 10 tables of 500GB each and 100 tables of 1MB, why not copy (using procopy or OS-copy) the whole DB and then (if necessary) drop the small tables or truncate their data-area(s)?
But if it's a matter of time, why not considering the problem from another point of view: If your DB has 10 tables of 500GB each and 100 tables of 1MB, why not copy (using procopy or OS-copy) the whole DB and then (if necessary) drop the small tables or truncate their data-area(s)?
Mike
Moderator
Dear Rob , I am really sorry to use capital words. but i just wrote coz i need ur help.
Dear Rob, I need the any pdf file for database administrator progress 10.2b . Its will be very great full for u.
Again my apologizes.
With regards Mike
Rob Fitzpatrick
ProgressTalk.com Sponsor
OpenEdge 10.2B product documentation is available here. I suggest you read the Database Essentials manual and the Database Administration manual.
Given what you have told us so far (which is very little), I am left to infer information about your situation: you are a relative newcomer to OpenEdge database administration, you have no one in-house to mentor you, you have a very large database that you want to dump and load, and the performance you see so far is not good enough for the needs of the business. I don't even know why you want or need to dump and load, or what you hope to achieve by doing so.
In some cases dump and load can be relatively simple; when the database is small it doesn't matter too much which approach you use (e.g. Dictionary dump and load, ASCII bulkload, binary dump and load; building indexes during or after the load). But when the database is very large the subject becomes much more complicated and subtle, as well as becoming broader in scope. That means you have to consider many other factors like database structure, server hardware, storage hardware and configuration, network performance, OS configuration (file system, user limits, etc.), and of course the window of allowable downtime provided by the business. You have fewer viable dump and load options and the penalties for making bad decisions are magnified.
Since you have not provided any specific information about your situation as requested, I can't help you with this task. The best recommendation I can provide about efficient dump and load of a very large database is that you don't try to do it by yourself. Find a reputable Progress database consultant in your area to help you. You will learn a lot from them and the result will be a much faster (and probably safer) dump and load than you can achieve on your own. And if you do hire a consultant, while they are on site don't forget to have them assess the safety of your data, i.e. whether your backup and after imaging strategy and procedures are sound.
Given what you have told us so far (which is very little), I am left to infer information about your situation: you are a relative newcomer to OpenEdge database administration, you have no one in-house to mentor you, you have a very large database that you want to dump and load, and the performance you see so far is not good enough for the needs of the business. I don't even know why you want or need to dump and load, or what you hope to achieve by doing so.
In some cases dump and load can be relatively simple; when the database is small it doesn't matter too much which approach you use (e.g. Dictionary dump and load, ASCII bulkload, binary dump and load; building indexes during or after the load). But when the database is very large the subject becomes much more complicated and subtle, as well as becoming broader in scope. That means you have to consider many other factors like database structure, server hardware, storage hardware and configuration, network performance, OS configuration (file system, user limits, etc.), and of course the window of allowable downtime provided by the business. You have fewer viable dump and load options and the penalties for making bad decisions are magnified.
Since you have not provided any specific information about your situation as requested, I can't help you with this task. The best recommendation I can provide about efficient dump and load of a very large database is that you don't try to do it by yourself. Find a reputable Progress database consultant in your area to help you. You will learn a lot from them and the result will be a much faster (and probably safer) dump and load than you can achieve on your own. And if you do hire a consultant, while they are on site don't forget to have them assess the safety of your data, i.e. whether your backup and after imaging strategy and procedures are sound.
TheMadDBA
Active Member
He gave you the link in his post... the word here is a hyperlink in this post and will take you to the site...
Or just click this https://community.progress.com/comm...164.openedge-10-2b-product-documentation.aspx
Or just click this https://community.progress.com/comm...164.openedge-10-2b-product-documentation.aspx
TheMadDBA
Active Member
Rob Fitzpatrick
ProgressTalk.com Sponsor
If you want to download a trial version of OpenEdge, go to progress.com and click the link that says "Try Now". You will be able to download a trial version of OpenEdge 11.4. You can't get a trial of 10.2B.
Rob Fitzpatrick
ProgressTalk.com Sponsor
Mike,
The subject of this thread is time-consuming dump and load. People who visit here later will expect posts in this thread to be about that subject. Your latest question is a completely different subject. Please create new threads for new subjects.
TheMadDBA
Active Member
Also if you have questions like that you need to make sure to include each step that you did in the process and when you got the error and the exact error message/number. Otherwise we can only guess at what the real problem is.
I would strongly suggest you start reading the DBA documentation and get up to speed on the concepts. If you know Oracle... make sure to try and forget all of that while you are learning Progress. They are two completely different beasts and most things will not work the same way as they do in Oracle. Of course there are common concepts but you need to try and start with a clean slate on Progress.
I would strongly suggest you start reading the DBA documentation and get up to speed on the concepts. If you know Oracle... make sure to try and forget all of that while you are learning Progress. They are two completely different beasts and most things will not work the same way as they do in Oracle. Of course there are common concepts but you need to try and start with a clean slate on Progress.
Similar threads
- Locked
- Jessica Malakian
- Progress Blog
