Legacy Product Discussions

Hitting the 255 snapshot limit on the snapinfo LUN

sojdehei
8,877 Views

Hello

This is very urgent!   IHAC that is hitting the 255 snapshot limit on the SnapInfo LUN.  This is happening when we already set to delete snapinfo snapshots in excess of 8.  Is there another place else in SMSQL to set number of snapshots retained for snapinfo?  filerview scheduler is already turned off for snapshots on snapinfo volume.  It looks like SMSQL is ignoring "in access of 8" completely?  Thank you for your help!

- Mitchell

28 REPLIES 28

sourav
7,721 Views

Hi Mitchell,

Can you check if there are any “Busy” snapshots in the list. If yes then you’ll have to take care of that by deleting that snapshot first and then all the snapshots thereof.

Regards,
Sourav Chakraborty

sojdehei
7,721 Views

Hi Sourav

Customer just replied: The statuses of the snapshots are all in a "consistent snapshot copy" state. Is there something else we should try? There are no busy snapshots. Could this be a bug?

Mitchell

http://www.netapp.com

marcconeley
7,720 Views

Was this problem ever fixed?

I have my SQL2005 configured with:

- 1 LUN for databases.

- 1 LUN for logs.

- 1 LUN for system dbs.

- 1 LUN for SnapInfo.

(this is a supported configuration).

Using SMSQL v5 I have hourly transaction logs backups, and daily full backups running. I keep all snaps for 7 days.

This works fine for all drives other than the SnapInfo drive - despite me setting "RetainSnapInfoDays 7" it never deletes any snapshots - in my case my volume then fills before I hit the 255 snapshot limit.

But I think its the same issue. I just had my NetApp consultants check the configuration last week but still the problem persists. Old SnapInfo snapshots just don't get deleted.

It would be great to know if/how you solved this.

Marc

sourav
7,720 Views

Hi Marc,

This is more of a design limitation wherein the Snapshots of the SnapInfo volume are not deleted automatically.

Let me delve more into this issue and I will get back to you by tommorrow.

Regards,

Sourav.

marcconeley
7,721 Views

Hi Sourav,

That would be great.

But then why is this a setting within SMSQL if it can't actually do this?

"RetainSnapofSnapInfoDays" is not only a parameter within the SQL jobs, but is also a configuration option which you get asked when you run the SMSQL Backup Wizzard.

I look forward to the results of your "delving"!

Cheers,

Marc

marcconeley
7,720 Views

Any further news on this?

Marc

sourav
7,720 Views

Hi Carl,

Can you check the value for the RetainSnapofSnapInfodays parameter? If this is 0 then please change it to some value and then check.

Alternately can you try using the RetainSnapofSnapInfo parameter with a non-zero value.

Are you running SMSQL 5.0 or SMSQL 5.0 R1?

Regards,

Sourav.

marcconeley
7,720 Views

Hi Sourav,

Sorry for hijacking this thread - but if it helps I am running SMSQL Version: 5.0.0.385.

And -RetainSnapofSnapInfoDays 7.

And I still have the problem (Snaps of the snapinfo drive are never deleted).

Any other suggestions?

marcconeley
8,155 Views

(Bump )

Is anyone else experiencing this issue?

Next step will be to set snapshot policy on the filer and let it handle the deletes of snapshots and not SMSQL because this is making me crazy.


And then I'll report it to NetApp as a potential bug & see what they say.

Doh.

rvhoutem
7,907 Views

Hi,

We had the same problem. The solution is to install the latest version of the snapmanager for SQL (SMSQL5.0R1P2_x86.exe).

marcconeley
7,907 Views

Great!

I will install the newest version tonight and post the results!

(I cant believe no-one else was experiencing these issues!).

sojdehei
7,907 Views

Hello

I just checked the NOW site and I don't see (SMSQL5.0R1P2_x86.exe) available for download? I do see (SMSQL5.0R1_x86.exe), is this correct?

- Mitchell

http://www.netapp.com

marcconeley
7,907 Views

Correct - I only see the SMSQL5.0R1_x86 download (I assumed it was the same one you were talking about as there was no mention of any others).

So if SMSQL5.0R1P2_x86.exe is a different update, then how did you get it & how do you know it fixes my issue?

rvhoutem
7,908 Views

Hi,

I know it will solve your problem because I had the same problem. I submitted a case and netapp support told me I was hitting bug 352690.

You can download the P2 version at http://now.netapp.com/NOW/download/software/snapmanager_sql2k/5.0R1P2/

Strange that netapp still has the wrong version on the now site

marcconeley
7,908 Views

Hi Ralph,

I wasn't the author of this thread so I can't flag it as "answered" - but I can confirm that this latest P2 version solved my problems!!

Why this version is not available on the NOW download site I have no idea.

I also find it amazing that so few people seem to have encountered this issue?!

Thank you for finally solving this for me Ralph!

Marc

abuchmann
6,543 Views

I had the same problem, so after reading this thread, I also updated to 5.0R1P2.

But I still have a problem, it looks like SMSQL does ignore the '-rtsifsnapdays' parameter.

The command

PS > new-backup  -svr 'SPS-V001'  -d  'SPS-V001', '2', 'MOSS_Content_BAGE', 'MOSS_Content_SPS2003' -rtdays  14 -lb -bksif -rtsifsnapdays 1 -trlog  -noutm  -gen -mgmt standard

gives me the following in the report

[16:14:26.896] 
[16:14:26.896]  *** DELETING LOG SNAPINFO DISK SNAPSHOT

[16:14:26.896]  Current time: 07.10.2009 16:12:32
[16:14:26.896]  Backups older than [20160] minutes ago will be deleted.
[16:14:26.912]  Backups older than [23.09.2009 16:12:32] will be deleted.
[16:14:26.912]  Get log snapshot list from LUN [S]: ...


[16:14:27.756]  There are total [44] snapinfo snapshot for LUN [S].
[16:14:27.756]  No backup data set will be deleted.

It looks like the snapinfo snapshots have the same retention as the db/log snapshots (14 days)

If I change the -rtsifsnapdays to another value (p.e. 30) it's the same:

[16:17:55.985] 
[16:17:55.985]  *** DELETING LOG SNAPINFO DISK SNAPSHOT

[16:17:55.985]  Current time: 07.10.2009 16:16:38
[16:17:55.985]  Backups older than [20160] minutes ago will be deleted.
[16:17:55.985]  Backups older than [23.09.2009 16:16:38] will be deleted.
[16:17:56.001]  Get log snapshot list from LUN [S]: ...


[16:17:56.751]  There are total [45] snapinfo snapshot for LUN [S].
[16:17:56.751]  No backup data set will be deleted.

Is this a normal behaviour?

marcconeley
6,545 Views

Not sure.

I installed the SMSQL5.0R1P2_x86.exe and it worked - but I am retaining both snapshots and "snaps of snapinfo" for the same length of time.


Here's how mine looks:

new-backup  –svr 'BNK-DB02'  -d  'BNK-DB02', '10', 'BAX40Production', 'BAX40test', 'BAX40Validation', 'INVOICES55', 'master', 'model', 'msdb', 'ReportServer', 'ReportServerTempDB', 'Servicedesk' -ver  –verInst 'BNK-DB02' -mp  –mpdir 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint' -RetainBackupDays  3 -lb -bksif -RetainSnapofSnapInfoDays 3 -trlog  -gen -updmir  –mgmt daily

Of course I am also using the long param names and you the short - but this shouldn't matter. I am sure that at one point I was keeping snaps of the snapinfo lun longer that my -retainBackupDays (and it worked).

I guess I could try increasing my-RetainSnapofSnapInfoDays to 5 and seeing what happens if you get desperate.

Normal behaviour? Not sure.

abuchmann
6,545 Views

When I'm using the same retention, It works for me too.

But i did some testing and what I see is that the snapinfo-snap retention is always the same as the -retainbackups(days).

Can you confirm this behaviour?

marcconeley
6,547 Views

OK.

I will change my retainsnap time to 4 days and tonight when it runs I'll post what happens.

marcconeley
6,754 Views

It seems that you're right although I really need a test environment before I can confirm this.


I changed the -retainsnapofsnapinfodays but it appeared to ignore it and keeps the same number as -retainbackupdays - so it appears that they're linked somehow.

I have many more snapinfo snaps than backups because I am running 30min log backups (which also creates a snapinfo snap) - but the number of daily snaps on the snapinfo lun = 4, which was the same number as my database lun.

I hope that helps confirm your theory.

Marc

Public