Re: NetApp SAN - monitoring aggregate free space
- From: Morgan <morgan@xxxxxxxx>
- To: avramil@xxxxxxxxxxxxxx
- Date: Sun, 31 Jul 2011 09:44:44 +0200
is it the aggregate or the volume filled up in your incidents?
The aggr commands you posted are working on the filer and not on the sun
box. if you have that access you can always issue aggr show_space
<aggregate_name> to get the picture of the aggregate sizing.
snapshot reserve on volume level in netapp only tells you how much
percentage of the volume that are reserved for snapshots, not letting your
ordinary data grow into this. The other way around though, the snapshots can
grow outside it's reserved space and fill up your volume. This happens alot,
especially if you store snapshots for a few days and have a lot of archiving
going on.
nothing is seen from smo when it comes to sizes, however if you have access
to the .snapshot directory you can always issue an du -sh inside it to get
how large the snapshots are, otherwise you need to ask someone with
filer-access to provide the information. on the filer: snap list
<volume_name> and snap delta <volume_name> should give you some interesting
output about snapshot sizing and growing.
//Morgan
2011/7/26 Lou Avrami <avramil@xxxxxxxxxxxxxx>
> Yeah ... the UNIX admin and the Storage admin are one and the same.
> In this environment the DBAs currently are barred access to the storage
> tools. I would definitely like to have access, but then I could also see
> how everything has been configured, or misconfigured, as the case may be
> ....
>
> The UNIX/Storage admin seems content to let this fail and then fix it,
> which is a drag.
>
> So yes, I am hoping for a technical solution to what is really a "human
> factors" problem.
>
> *
>
> Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote:
>
> *
>
> In your situation you can *only* get a true view of things, including
> snapshot reserve space and all the rest of it by using the netapp storage
> level tools. smo doesn't give you that info. Time to either make good
> friends with the storage guys or become a DBA 2.0 (in the original sense)
> and bring netapp storage into your realm and skillset. Good luck with
> either. Incidentally your Unix admins likely *also* can't see the true
> picture unless they are the storage admin as well.
>
> On Tue, Jul 26, 2011 at 9:34 PM, Lou Avrami <avramil@xxxxxxxxxxxxxx>wrote:
>
>> Hello oracle-l,
>>
>> We have an Oracle 11.2.0.2 RAC on a 2-node Solaris 10 cluster on a NetApp
>> FAS6080. This database is somewhat large, approximately 18 TB. We are
>> using NetApp Snap Manager 3.1 for online database backups.
>>
>> We've had two incidents now where the SAN Aggregate for the archive
>> destination has "filled up", despite the fact that the ASM disk group is
>> only at 50% of capacity.
>>
>> Does anyone know of a command-line utility that could give us information
>> on the status and free space of the aggregate? Our UNIX/Storage admin is
>> "working on the problem" ... but our wait for a fix or a correction to the
>> configuration could be quite long. We don't have access to the NetApp tools
>> that are used to configure and monitor the SAN. I was hoping that there
>> might be something that could be run that could at least give us a warning
>> when space was becoming an issue at the aggregate level.
>>
>> I've tried
>>
>> $ sanlun lun show -p -v all
>>
>> and that displays a lot of info, but there appears to be no options with
>> sanlun that have details on aggregate space.
>>
>> I did come across this webpage:
>>
>> http://www.datadisk.co.uk/html_docs/netapp/netapp_disk.htm
>> http://www.datadisk.co.uk/html_docs/netapp/netapp_cs.htm
>>
>> Both mention the "aggr" command:
>>
>> aggr status
>> aggr status -r
>> aggr status <aggregate> [-v]
>>
>> but I can't locate aggr on our Solaris servers.
>>
>> If anyone has any suggestions, they would be most welcome.
>> Thanks,
>> Lou Avrami
>> --
>> //www.freelists.org/webpage/oracle-l
>>
>>
>>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>
> -- //www.freelists.org/webpage/oracle-l
Other related posts:
