Has anyone used dbaascli to rename db_unique_name ? (Questions)

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Wed, 21 Oct 2020 14:08:59 -0400
Message-ID: <CAP79kiQwvRQMaV5QwkZwikFshCbxeW9hKLH0Ly0OitfNuu9sEw_at_mail.gmail.com>

So I just renamed a small database on Exadata using the dbaascli update database --db_unique_name (
https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/dbaascli-database-update.html )

And checking the ASM structures, it appears that it *cloned* the database at the ASM layer?

Has anyone else noticed that? That could be a nasty surprise for a 100TB+ database (think standby database reconfig)

*OLD_NAME:*

ASMCMD> pwd
+DATAC1/TPDBPR01/DATAFILE ASMCMD> ls -ls --absolutepath

Type      Redund  Striped  Time             Sys  Block_Size  Blocks
Bytes       Space  Name
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => SYSAUX.3862.1054208095
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => SYSTEM.3863.1054208095
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => UNDOTBS1.3860.1054208095
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS2.3876.1054208437
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS3.3866.1054208441
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS4.3838.1054208447
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS5.3880.1054208451
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS6.3885.1054208457
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192   12801

104865792 339738624 none => USERS.3859.1054209031

*NEW_NAME:*

ASMCMD> pwd
+DATAC1/TPDBPR01_MIA/DATAFILE ASMCMD> ls -ls --absolutepath

Type      Redund  Striped  Time             Sys  Block_Size  Blocks
Bytes       Space  Name
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => SYSAUX.3778.1054385005
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => SYSTEM.3771.1054384997
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  256001
 2097160192  6316621824  none => UNDOTBS1.3811.1054385011
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS2.3899.1054384961
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS3.3833.1054384969
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS4.3832.1054384977
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS5.3831.1054384983
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192  262145
 2147491840  6467616768  none => UNDOTBS6.3830.1054384991
DATAFILE  HIGH    COARSE   OCT 21 12:00:00  Y          8192   12801

104865792 339738624 none => USERS.3789.1054385041

That seems like it creates a clone - unless I'm missing something?

I can't find any documentation that says anything remotely like that however. I closest is this blurb in the oracle docs:
*File locations that reference the globally unique database name are also
updated, including the location of the data files and keystore. *

Chris

--
http://www.freelists.org/webpage/oracle-l

Received on Wed Oct 21 2020 - 20:08:59 CEST