关于lsdg的 -Req_mir_free_MB 和Usable_file_MB讨论帖

Maclean Liu(刘相兵

关于lsdg的 -Req_mir_free_MB 和Usable_file_MB讨论帖

from Lunar:

可以使用的总空间(不考虑oracle所说的安全使用的情况)为 Total_MB/2  <--------初始部署时,以这个值来判断容量
目前可以使用的总空间(不考虑到安全使用)为  Free_MB/2  <---------在使用一段时间后,用这个值来判断可用容量
可以安全使用的总空间是     (Total_MB-Req_mir_free_MB)/2
目前可以安全使用的空间是   (Free_MB-Req_mir_free_MB)/2  即Usable_file_MB 的值


Usable_file_MB意味着
Free_MB < Req_mir_free_MB，即空闲空间小于镜像要求的空余空间， 这会导致 如果丢失磁盘 后将不能 rebalance 。
如果你允许这种情况发生，那么 你可以让Usable_file_MB 仍为负值。

否则：
将部分非必要的文件移出该diskgroup
or
扩容diskgroup空间

Maclean Liu(刘相兵

ODM FINDING:

Cell Usable File MB and Disk Usable File MB are similar to the column, USABLE_FILE_MB, in V$ASM_DISKGROUP and are computed by the script. When
FREE_MB is less than the reserve space, you will see the usable file MB value become a negative number. This means that you will be unable to rebalance
after the loss of a cell or disk, depending for which coverage you chose to reserve space.
If you are reserving space for disk failure coverage, you may see V$ASM_DISKGROUP.USABLE_FILE_MB become negative because the amount of reserve space for
disk failure coverage is much less than REQUIRED_MIRROR_FREE_MB that is used for computing USABLE_FILE_MB in the view. This is acceptable and supported as
long as you have decided that disk failure coverage is suitable for your system.
Please note that you must monitor V$ASM_DISKGROUP.FREE_MB to ensure that it never goes below Disk Required Mirror Free MB or Cell Required Mirror Free
based on your choice of failure coverage. Or, you can run the attached script periodically and ensure that, Disk Usable File MB or Cell Usable File MB never become
negative values (or show they PASS the space tests), based on your choice of failure coverage.
Additional Considerations
Its important to have a monitoring strategy using EM or custom scripts (possibly utilizing the attached script) to ensure that you keep FREE_MB above the
Cell Required Mirror Free MB or Disk Required Mirror Free MB at all times.
If you decide to reserve space for disk failure coverage, you may eventually see V$ASM_DISKGROUP.USABLE_FILE_MB become negative - this is expected
depending on the reserve space you've chosen, but again, you must have a monitoring strategy in place to ensure you keep the amount of space needed for
disk failure coverage in reserve.
If you have planned for disk failure coverage, it is a good idea to extend the time of the ASM disk group attribute disk_repair_time to a value that reflects
the expected time to repair a cell (e.g., 24 hours). This will prevent a rebalance from starting and instead will use the much faster resync capability when
the cell is back online. If a rebalance does start, it is expected that you will not have space to complete the rebalance and at some point you may receive an
ORA-15041 error. When the cell is returned to service, the disks will be added back in and the ORA-15041 will be cleared when the rebalance completes.
The datasheet calculations assume enough free space for the case of a single disk failure on normal redundancy disk groups and a typical DATA/RECO
distribution of space like (80/20). For all rack sizes, the total space needed by all disk groups add up to less than two complete physical disks (this
calculation is left to the reader). This requirement is applicable to configurations with the 11.2.0.3 version of ASM and may vary for other versions.

ziyoo0830

mark ......

aaronqlm

收藏之~~~~~~~~~~

Maclean Liu(刘相兵

HOT_USED_MB + COLD_USED_MB in v$asm_disk should give the space utilization at each ASM disk level.
Mostly it will be COLD_USED_MB as HOT_USED_MB will be 0 in most cases, until you have implemented IDP(intelligent data placement).
In that case, HOT_USED_MB for such a disk will be a non-zero number and the COLD_USED_MB for that disk will be less by that equivalent amount.
Regardless, it will be the summation of HOT_USED_MB and COLD_USED_MB to give the space utilization for each ASM disk.
And in addition to that, v$asm_disk also has the OS_MB, TOTAL_MB and FREE_MB columns. TOTAL_MB – FREE_MB will also give the disk utilization.
So there are numerous ways you can achieve this from v$asm_disk itself.


If you'd like to know which asm file is sitting on a particular disk, you can use one of the following sqls.

1. at.sql
select group_kfdat, number_kfdat, fnum_kfdat, count(*) from x$kfdat     -- fnum_kfdata is asmfile#
where group_kfdat=6    -- diskgroup number
and fnum_kfdat != 1048575
group by group_kfdat, number_kfdat,  fnum_kfdat
/


2. fn.sql
~~~~~~~~~
set linesize 120
col name format a50

select group_kffxp, disk_kffxp, number_kffxp, count(au_kffxp)      -- number_kffxp is asmfile#
from x$kffxp f
where ( xnum_kffxp != 2147483648 and disk_kffxp != 65534 and au_kffxp != 4294967294 )
--and number_kffxp = 282  -- file number
and group_kffxp=6       -- diskgroup number
group by group_kffxp, disk_kffxp, number_kffxp
order by group_kffxp, disk_kffxp, number_kffxp
/