Re: exp/imp Oracle 7.3

On Mon, 29 Jun 1998 08:54:13 +0100, MotoX <at_at_at.com> wrote:
>Still, the point I made is valid: Never use compress=y unless you have
>checked the db, know it well, know you have a problem with it's design, and
>know that using compress will not cause further problems. The original
>poster should take this on board.
>
>MotoX.

I guess I just have a problem with "never." I find a compressed, redundant, cold backup with exp can be a lifesaver in many situations. So much so that I use it routinely, even though over the years I've had far too many problems with exp/imp. I spent a lot of time walking into unknown situations, and setting up some backup redundancy is my highest priority in such cases. It's amazing how much bad DBA work has been done out there, I've learned to never assume that any db has necessarily been done right. I guess we'll have to agree to disagree here.

>
>Joel Garry wrote in message ...
>>On Thu, 25 Jun 1998 08:47:33 +0100, MotoX <at_at_at.com> wrote:
>>>I take issue with the compress=y. I always set it to 'n', but then I
>design
>>>and implement my databases properly following the Oracle White Papers on
>>>Space Management. Compressing the extents blows all that design and
>>>implementation work out the window.
>>
>>I take issue with your issue. Many situations arise in the real world
>>where either the volume of data cannot be known at the time of initial
>>table creation, or the implementation was done improperly for any number
>>of reasons, from silly to practical. I find compress=y useful in many
>>of these situations, particularly coming into a screwy development
>>environment, or even production environments that have lacked proper DBA's
>>for a period of time. There is such a thing as "growth," too. Consider
>>yourself lucky to be in an environment where you can assume you have the
>>time and resources to do it all properly.
>>
>>Cool email address, though.
>>
>>>
>>>MotoX.
>>>
>>>MMK Productions wrote in message <6msct9$e6t_at_world6.bellatlantic.net>...
>>>>You might want to use a parameter file to include the export/import
>>>>parameters. This is an ASCII file with the parameters on each line.
>>>>
>>>>Here is an example for your question:
>>>>
>>>># filename: db1fulexp.par
>>>>userid=system/manager
>>>>log=db1fulexp.log
>>>>file=/dir1/exports/db1fulexp.dmp
>>>>full=y
>>>>buffer=500000
>>>>indexes=y
>>>>rows=y
>>>>grants=y
>>>>compress=y
>>>><the line above was the last line of the file>
>>>>
>>>>You can use a similar file for imports
>>>># filename: db1fulimp.par
>>>>userid=system/manager
>>>>log=db1fulimp.log
>>>>file=/dir1/exports/db1fulexp.dmp
>>>>full=y
>>>>commit=y
>>>>buffer=500000
>>>>ignore=y
>>>><the line above was the last line of the file>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>--
>>These opinions are my own and not necessarily those of Information Quest or
>>Pebble In The Sky http://www.informationquest.com
>mailto:jgarry_at_nospameiq.com
>>http://ourworld.compuserve.com/homepages/joel_garry Remove nospam to
>reply.
>>mailto:joel_garry_at_compuserve.nospam.com "See your DBA?" I AM the @#%*&
>DBA!
>
>

--
These opinions are my own and not necessarily those of Information Quest or Pebble In The Sky http://www.informationquest.com mailto:jgarry@nospameiq.com http://ourworld.compuserve.com/homepages/joel_garry Remove nospam to reply. mailto:joel_garry_at_compuserve.nospam.com "See your DBA?" I AM the @#%*& DBA! Received on Mon Jun 29 1998 - 16:39:57 CDT