Removing
cell security on the cells is fairly simple. In order to remove cell security
on the griddisks, we need to remove database-scoped security first, before
removing asm-scoped security.
To implement cell security, please refer to my previous post Securing Exadata Machine
Steps to
remove Database-Scoped Security:
Ø Stop CRS
& DB services
Ø Remove
database client’s name from the availableTo attributes from a set of griddisks
dcli –l root –g ~/cell_group “cellcli –e alter
griddisk <griddisk_names> availableTo=’+asm’”
Ø If no other
griddisk is assigned to any other database client then we can remove the key
assigned to a database.
dcli –l root –g ~/cell_group “cellcli –e assign key
for <db_name>=’ ‘”
Ø remove the
cellkey.ora file from $ORACLE_HOME/admin/db_unique_name/pfile/ directory
Ø Remove the
database from the availableTo attribute
dcli –l root –g ~/cell_group “cellcli –e alter
griddisk all availableTo=’+asm’
Ø Restart CRS
& DB services
Removing ASM-Scoped
Security
ASM-Scoped security is removed once
database-scoped security is removed from the cell storage. After removing
asm-scoped security, there would be open-security for griddisks on cells.
Steps to
remove ASM-Scoped Security:
Ø Stop CRS
& DB services
Ø Remove Oracle
ASM client’s name from the availableTo attributes from a set of griddisks
dcli –l root –g ~/cell_group “cellcli –e alter
griddisk <griddisk_names> availableTo=’ ’”
Ø If no other
griddisk is assigned to any other ASM cluster client then we can remove the key
assigned to a database.
dcli –l root –g ~/cell_group “cellcli –e assign key
for <asm_cluster>=’ ‘”
Ø remove the
cellkey.ora file from /etc/oracle/cell/network-config/ directory from each
compute nodes
Ø Remove
Oracle ASM fro`m the availableTo attribute
dcli –l root –g ~/cell_group “cellcli –e alter
griddisk all availableTo=’ ’”
Ø Restart CRS & DB services
Ref:
Expert Oracle Exadata by Kerry Osborne, Randy Johnson, and Tanel Poder
Oracle Exadata Recipes by John Clarke
Bye,
Saurabh
