Just use asmcmd. For example:
[oracle@oel61 ~]$ . oraenv
ORACLE_SID = [+ASM] ? +ASM
The Oracle base remains unchanged with value /u01/app/oracle
[oracle@oel61 ~]$ asmcmd lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 ...
This assumes that you've already partitioned the presented disk(s) (and will be using /dev/sd[whatever]N), and that you're using asmlib. There will be a kernel module loaded if you are:
[root@oel61 disks]# lsmod | grep oracle
oracleasm 53865 1
As root, scan for candidate disks:
[root@oel61 ~]# /etc/init.d/oracleasm ...
The recommendation is to have log switches occur a few times an hour. If you have a 100 log switches an hour with 50MB redo logs, you need e.g 1GB redo logs for 5 log switches/hour.
100*50 MB redo/hour for a 6.5GB database is unusually much though.
You can add the new logs, e.g:
ALTER DATABASE ADD LOGFILE THREAD 1 SIZE 1G;
ALTER DATABASE ADD LOGFILE THREAD ...
KISS principle: Do you have the storage that itself offers you the required availability level (i.e. disk array)? And you do have RMAN backups with a recovery catalog (you need it anyway, for DUPLICATE), don't you? If yes and yes, my version is: no secondary control file at all, one member per each redo group, as there are no secondary datafiles (quite ...
i've found the definitive answer from the oracle docs
in the Oracle Database Standard Edition and Oracle Real Application Clusters (Oracle RAC) section, it specifies
"Oracle Automatic Storage Management is required for creating and managing all Oracle database file types. Raw ...
I have drop this diskgroup from target host and then with " oracleasm deletedisk "
This was a mistake. You removed the metadata describing the content. You should have just simply detached the disks, then attach to the new host, leaving the disks intact.
Imagine the following.
On 2019-08-19 18:00:00 you started a full online database backup that took 5 minutes. This backup included all the datafiles listed above.
Backuppieces created from this operation:
arch1.bkp - backup of archivelogs that existed before starting the full database backup + the last archivelog that was created as a result of the ...
col gname form a10
col dbname form a10
col file_type form a14
regexp_substr(full_alias_path, '[[:alnum:]_]*',1,4) dbname,
Just make sure auto controlfile backup is turned on. If you added or dropped a datafile(s) before the controlfile was backed up, and you had a hardware failure which resulted in the single CF not be accessible, it would be a pain to restore...not impossible, just a huge pain and a time sink during a sensitive time resuming services.
The Oracle docs for 11.2 ASM migration are here:
These explain the process that you need to go through to migrate to ASM from filesystem storage.
First of all, I checked that there were no extents on DISK1.
$ . oraenv
ORACLE_SID = [+ASM1] ?
SQL> select PXN_KFFXP, -- physical extent number
XNUM_KFFXP, -- virtual extent number
DISK_KFFXP, -- disk number
AU_KFFXP -- allocation unit number
no rows selected
I cleared the ...
DISCLAIMER : Not an Oracle DBA
Use srvctl, the grid control program that allows you to manipulate parts of the RAC Cluster
Usage: srvctl <command> <object> [<options>]
I found the solution.
----------shutdown database instance first
$sqlplus / as sysdba
SQL> shutdown immediate;
---------stopping Oracle Clusterware, It will shutdown ASM instance itself
$ su -
# cd /u01/app/11.2.0/grid/bin/
# ./crsctl stop ...
Why not just create luns on the new storage, with same size as on old storage and add them to the existing disk groups. Next drop the old disks from the disk group and when the re-balance is over, your system is migrated to the new storage, without any downtime.
Works like a charm. ASM is way smarter than a filesystem.
Transportable tablespaces and asmcmd cp command should do the trick.
Prepare transportable tablespaces metadata set.
Copy expdp file to location accessible by impdp from destination database.
asmcmd cp datafiles to new location.
Import TT metadata set.
If your ASM diskgroup uses some storage device with several disks then you should be able to improve ...
Oracle RAC requires a clustered file system:
ASM comes with the database
ASM provides a clustered file system
ASM was built specifically to do this
Anything else would be an additional cost 3rd party product that you would have to integrate and get working with your Oracle RAC.
Your permissions are incorrect.
Oracle recommends role separation, which it appears you've followed by creating separate oracle and grid users. But I'm willing to wager that your ORACLE_HOME is under /u01/app/database or similar, which means that the chmod and chown commands you ran also changed permissions and ownership on the database home, too. This ...
You won't need downtime just to add additional redo logs to your redo groups.
Take a look at this:
Oracle Configuration Best Practices
And then look at this:
Creating Redo Log Groups and Members
You will need downtime to add additional control files:
Creating Additional Copies, Renaming, and Relocating Control Files
First of all, people often fall for this, but high log file sync waits do not necessarily mean I/O problem.
Second, this could be really troublesome, if you have many physical devices in the ASM diskgroup where your redo logs are, because the extents of your files will be evenly distributed on several disks.
Anyway, you need to find the ASM diskgroup ...
This can be caused by the asm_diskgroups parameter. On older releases (like 11g), this was a typical problem. This parameter was automatically updated, except when a diskgroup was dropped, then its name was not removed from the parameter values.
You can check this if you have access to MOS:
Dropped Diskgroup Still Existing in ASM spfile (Doc ID 2241177.1)
First find the disk names and paths:
select name, failgroup, path, os_mb, total_mb, free_mb from v$asm_disk;
After you found the ASM generated name for the disk you want to shrink, reduce it in ASM to the desired size (I will assume it is called DATA1_0002:
alter diskgroup data1 resize disk DATA1_0002 size 90G;
This starts a rebalance, wait until the ...
ORA-15041: diskgroup space exhausted
Cause: At least one disk in the diskgroup is out of space.
Action: If all disks are evenly balanced, add more disks to the diskgroup.
According to the log provided in the question, i found that it was unable to complete the archiving operation as the asm diskgroup '+FRA_DATA' is full. The DML operation on ...
ASM metadata describes the location of the password file on the ASM disk. With that information, even you can read it directly from the disk, with the help of kfed (which is installed with the Oracle binaries) and OS specific tools for reading the disk directly, for example dd, without using ASM. Same goes for the SPFILE (since 11g).
More about this topic:
Check if autostart for Oracle Restart is enabled:
$ cat /etc/oracle/scls_scr/$HOSTNAME/oracle/ohasdstr
If it is not enabled, then enable it:
crsctl enable has
Check if ASM autostart is enabled:
crsctl stat res ora.asm
If ASM is not registered in GI, add it with:
srvctl add asm ...
Check if used diskgroups are registered:
srvctl status ...