Subscribe

volume-get-iter iteration tag not working as expected

hi,

 

Just read the posts about volume-get-iter and I believe it's not exactly the same problem reported on those, therefore I wanted to post here as a new one.

 

I have some code to do consistent snapshots on RDBMS databases. Since a few days the code has started to fail. Not always but some times, which makes whole problem a little bit more wierd.

 

The query I am dispatching the to controller using a vsadmin account is:

 

<volume-get-iter>
        <max-records>10</max-records>
        <query>
                <volume-attributes>
                        <volume-id-attributes>
                                <junction-path>/CRS/dbs03/EMREPP</junction-path>
                        </volume-id-attributes>
                </volume-attributes>
        </query>
        <desired-attributes>
                <volume-autosize-attributes></volume-autosize-attributes>
                <volume-id-attributes></volume-id-attributes>
                <volume-space-attributes></volume-space-attributes>
                <volume-state-attributes></volume-state-attributes>
        </desired-attributes>
</volume-get-iter>

 

This should retrieve just one record (out of ten possible). And it has done for the last 24 months. But now it retrieves one record and 'next-tag' attribute set to:

<volume-get-iter-key-td>
        <key-0>vs1rac51</key-0>
        <key-1>emreppcrs03</key-1>
</volume-get-iter-key-td>

 

So I query again, and then I obtain nothing. I sure can handle this in my code, but I was expecting to only use 'next-tag' when there was something else remaining to be fetched, which it's not the case.

I am querying again an Ontap 8.2.2P1 clustered system (8 nodes).

 

Thank you,

Ruben

Re: volume-get-iter iteration tag not working as expected

Related with this issue I would like to mention that queries by junction-path takes longer and longer on one of our clusters (all the clusters bellow run Ontap 8.2.2P1):

 

- it takes 100 secs, on a cluster made of 8 nodes  about 540 volumes (NFS).

 <volume-get-iter>
        <max-records>10</max-records>
        <query>
                <volume-attributes>
                        <volume-id-attributes>
                                <junction-path>/CRS/dbs03/EMREPP</junction-path>
                        </volume-id-attributes>
                </volume-attributes>
        </query>
        <desired-attributes>
                <volume-autosize-attributes></volume-autosize-attributes>
                <volume-id-attributes></volume-id-attributes>
                <volume-space-attributes></volume-space-attributes>
                <volume-state-attributes></volume-state-attributes>
        </desired-attributes>
</volume-get-iter>

 

-- 13 secs, 14 nodes cluster about 540 volumes. NFS access. About 145 volumes. NFS and iSCSI access.

 <volume-get-iter>
        <max-records>10</max-records>
        <query>
                <volume-attributes>
                        <volume-id-attributes>
                                <junction-path>/ORA/dbs03/ENCVORCL</junction-path>
                        </volume-id-attributes>
                </volume-attributes>
        </query>
        <desired-attributes>
                <volume-autosize-attributes></volume-autosize-attributes>
                <volume-id-attributes></volume-id-attributes>
                <volume-space-attributes></volume-space-attributes>
                <volume-state-attributes></volume-state-attributes>
        </desired-attributes>
</volume-get-iter>

 

 

 

-- 6 secs, 2 nodes cluster

 

<volume-get-iter>
        <max-records>10</max-records>
        <query>
                <volume-attributes>
                        <volume-id-attributes>
                                <junction-path>/backup/dbs01/ENCVORCL</junction-path>
                        </volume-id-attributes>
                </volume-attributes>
        </query>
        <desired-attributes>
                <volume-autosize-attributes></volume-autosize-attributes>
                <volume-id-attributes></volume-id-attributes>
                <volume-space-attributes></volume-space-attributes>
                <volume-state-attributes></volume-state-attributes>
        </desired-attributes>
</volume-get-iter>

 

 

How  can I track where the time is spent? how I can debug this a little,who is running the query on a cluster, where are log files located?

 

Thank you

Re: volume-get-iter iteration tag not working as expected

Apologies, where you read:

 

-- 13 secs, 14 nodes cluster about 540 volumes. NFS access. About 145 volumes. NFS and iSCSI access

 

You should read:

 

-- 13 secs, 14 nodes cluster about 540 volumes. NFS access.

 

And  where you read:

 

-- 6 secs, 2 nodes cluster

 

you should read:

 

-- 6 secs, 2 nodes cluster. About 145 volumes. NFS and iSCSI access

 

Thank you.