to Locally-Managed Tablespaces
Jared - I don't know SAP, but other canned applications have
a wonderful
process they put you through every few years called an
upgrade. Often you
end up creating another database and moving the data. This is a great
opportunity for the DBA to fix some issues
Tanel
I am curious - why are you forced to keep
segments in specifically named tablespaces.
I did come across one system that would
actually reject (application) upgrades if the
database didn't have exactly the right two
tablespaces (E_DATA and E_INDX or
some such) but I can't think of any
Hi
I am curious - why are you forced to keep
segments in specifically named tablespaces.
This Concorde XAL application has an internal repository which stores information
about physical segment structures (as tablespace name, initial next extent etc).
And it can start reorganizing segments
The answer is in my book.
Assume your original setting for pctfree is correct,
by the time rows are full length, they are filling
the block. If any rows are still part-grown, there
will be the right amount of space left in the block
for them to grow. If all the rows are new, there
will be
Two questions for you:
1. The export file is binary format. Can you tell me
which editor you use?
2. How to manually parallel?
Thanks.
--- zhu chao [EMAIL PROTECTED] wrote:
Hi, Tanel:
If you have plenty of downtime, everything will
be ok.
If you want to further limit the
An additional consideration: If you convert the tablespaces in place with
dbms_space_admin, check the default storage for initial and next extent.
When you do the conversion with dbms_space_admin, a space header is created
and the extent allocation for the space header will be whatever the
Hi,Thank you all for your prompt suggestions. I was leaning towards EXP/IMP due to its small size. I will test out some of your suggestions in our test environment nevertheless.
- Paula W.
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
Jared - I don't know SAP, but other canned applications have a wonderful
process they put you through every few years called an upgrade. Often you
end up creating another database and moving the data. This is a great
opportunity for the DBA to fix some issues like this. However, since SAP is
used
Well I don't know about SAP either, thank GOD. PeopleSoft does maintain the
tablespace where tables and index are suppose to reside so that come upgrade time you
can see what's moved, but at least they provide a rather painless way to change that
if needed.
Dick Goulet
Senior Oracle DBA
Hi
Obviously I'm not Tanel, but we have a similar situation where we don't
actually need to keep segments in specifically named tablespaces - but we do
need when upgrading all of the specifically named tablespaces to exist, and
have sufficient free speace for the upgrade. The app is
Hi,
I just use vi :%s/oldtablespacename/newtablespacename/g to edit the dump file and
import it back.In my case, it did work. And it is oracle supported method of renaming
tablespace in versions before 10g.
Manual parallel means:
I have to move 10 table, for example, so in one
SAP expects tables to be in certain tablespaces: PSAPBTABD for instance.
Same with indexes: PSAPBTABI
The SAPDBA interactive tool is being phased out in favor of the
command line tool brconnect. I don't know if brconnect allows
some flexibility in tablespace names, but I doubt it. Just
On a gig of data, you could easily export the data and re-import into
new locally managed tablespaces.
An alternative is to use the dbms_space_admin package to convert
DD managed tablespaces to locally managed.
This is what I will need to use on our systems, as there are about 400 gig
of
Hi!
This is what I will need to use on our systems, as there are about 400 gig
of data and indexes. 200 gig of data is too large to export/import, at
least
it is for this project. So dbms_space_admin it will be.
I'm about to do a reorg+conversion of a 250GB 8.1.6 database in next week,
A small addition, PK/UQ constraints have to be disabled in order to drop
their indexes (and index definitions should be exported before disabling
constraints, because implicitly created indexes will be automatically
dropped if a constraint is disabled (without keep indexes option)).
Tanel.
I'm
Hi,
Think what benefit can you get via such reorg before doing this reorg.
Since only a small database, I won't change it as performance benefit via reorg
will be small.
As others said, exp/imp is the most easy way, as movetable/rebuild index has
trouble sometimes when you have long
Tanel,
That's a good idea. I briefly considered this, but
didn't really dig into it.
The systems I need to do this on is our SAP systems, and
downtime is a precious commodity, especially for production.
I just may try this on our test system. The problem with
SAP of course, and many other
I can see you everywhere :D
Hi,
Think what benefit can you get via such reorg before doing this reorg.
Since only a small database, I won't change it as performance benefit via reorg
will be small.
As others said, exp/imp is the most easy way, as movetable/rebuild index has
Hi, Tanel:
If you have plenty of downtime, everything will be ok.
If you want to further limit the downtime, here is some suggestions:
1. I think manual parallel will always be better than oracle parallel. So I always use
script, that means, I split the move table nologging script to 10
19 matches
Mail list logo
