2 Replies Latest reply: Mar 27, 2013 1:47 AM by chao RSS

SMSQL 6.0 issue: DB backup archival setting is gone and could not re-configure them.

chao
Currently Being Moderated

Hi Gurus

I met a strange SMSP/SMSQL issue about archive/dataset setting.  Here is a SMSP6.1.1+SMSQL6.0+SDW6.4.2+Snapvault environment.  we configure two backup(plus archival) jobs. one is SMSP job and one is SMSQL job for some non-Sharepoint DB.  of coz, SMSP DB+Log and non-sharepoint DB+log were stored in separate LUN/volumes.  all LUN occupied a dedicated volume and were put under Qtree.

Those two SMSP/SMSQL backup (plus archival) were always well.  but about 5 days ago,  SMSP jobs report error.

after checking the SMSQL log:  it includes:

[DC01-SQL-01] WARNING: SnapInfo snapshot archiving is skipped due to invalid dataset name.

 

[DC01-SQL-01] Error Code: 0xc004096d Unable to perform SnapInfo directory archive backup operation. Database selected is either not configured for backup archive, or unable to perform backup archive due to failure during the primary backup.

we found on primary storage, the related backup (snapshot) were generated but could not be archived to Secondary side.   but the SMSQL job could be completed (archived) successfully.

We suspected the SMSQL archival setting.  after checking, we found all SMSP were unselected)  (in fact, no one change that) and I could not even re-select them. It reported Primary storage is not configured properly or LUNs are not kept under Qtree.

clip_image002.jpg

 

 

 


But those SMSP DB/log and non-Sharepoint DB are stored in same Primary storage (of coz, also be archived to same secondary storage).  and all LUNs are also put under qtree.

dc01-st3240a-01> lun show

/vol/EX_01_DB1_A/Q1/EXDB01  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_01_DB1_A_LOG/Q1/EXDB01LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_01_DB6_P/Q1/EXDB06  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_01_DB6_P_LOG/Q1/EXDB06LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_02_DB2_A/Q1/EXDB02  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_02_DB2_A_LOG/Q1/EXDB02LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_02_DB7_P/Q1/EXDB07  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_02_DB7_P_LOG/Q1/EXDB07LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_03_DB3_A/Q1/EXDB03  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_03_DB3_A_LOG/Q1/EXDB03LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_03_DB8_P/Q1/EXDB08  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_03_DB8_P_LOG/Q1/EXDB08LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_04_DB4_A/Q1/EXDB04  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_04_DB4_A_LOG/Q1/EXDB04LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_04_DB9_P/Q1/EXDB09  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_04_DB9_P_LOG/Q1/EXDB09LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_05_DB10_P/Q1/EXDB10  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_05_DB10_P_LOG/Q1/EXDB10LOG  100.0g (107389255680)  (r/w, online, mapped)

/vol/EX_05_DB5_A/Q1/EXDB05  500.1g (536946278400)  (r/w, online, mapped)

/vol/EX_05_DB5_A_LOG/Q1/EXDB05LOG  100.0g (107389255680)  (r/w, online, mapped)

        /vol/SECPORTAL/Q1/LUNDATA1  500.1g (536946278400)  (r/w, online, mapped)    -Sharepoint DB

/vol/SECPORTAL02_DB/Q1/LUNDB   30.0g (32169070080)   (r/w, online, mapped)   - non-Sharepoint DB

/vol/SECPORTAL02_LOG/Q1/LUNLOG   30.0g (32218421760) (r/w, online, mapped)  - non-Sharepoint DB LUN

/vol/SECPORTALCLUSTER/Q1/LUNQUORUM1    1.0g (1077511680)    (r/w, online, mapped)

/vol/SECPORTALCLUSTER/Q2/MSDTC01    5.0g (5371107840)    (r/w, online, mapped)

        /vol/SECPORTAL_LOG/Q1/LUNLOG1   44.0g (47246008320)   (r/w, online, mapped) –Sharepoint DB log

/vol/SECPORTAL_SNAPINFO/Q1/LUNSNAPINFO1 35.0g (37581304320)   (r/w, online, mapped)

/vol/SECPORTAL_SYSDB/Q1/SECPORTAL_SYSDB   20.0g (21476206080)   (r/w, online, mapped)

/vol/SECVM01/Q1/LUN0         200g (214748364800)  (r/w, online, mapped)

 

 

I have no idea what’s the root cause.  Any input are appreciated.

 

BTW,  I could manually trigger SDW to do snapvault.

 

BR

TC

  • Re: SMSQL 6.0 issue: DB backup archival setting is gone and could not re-configure them.
    welch
    Currently Being Moderated

    What is the status of your SnapVault realtionships for those qtrees in system manager, and protection manager?  When was the last time the vault succeeded?  The reason the SnapVault option is greyed out in SMSQL and SMSP is likely because either protection manager does not recognize the vault relationship, or the filers dont.  Also check your data protection policy in protection manager.  make sure the protection manager server, the server running snapmanager, and the storage controllers can all communicate.  Check the volume status on both the source and destination.  Look for full volumes, or volumes with a max number of snapshots (254). 

    • Re: SMSQL 6.0 issue: DB backup archival setting is gone and could not re-configure them.
      chao
      Currently Being Moderated

      I almost found the root casue. 

      It seems sharepoint automatically generate a new DB (performance*********) and deployed to storage by default.  it's a little strange that LDF place is correct but MDF place is at system DB location.  because SMSP job does not include this DB (no sync farm yet), then SMSP local backup works well. non-sharepoint MDF/LDF are at another seperate LUNs,  so non-sharepoint DB SMSQL backup job is unimpacted.

      but I don't know why it automatically unselected DB from dataset.

       

      Tonight, we plan to migrate the DB to right place and check what will happen for backup archival seting

More Like This

  • Retrieving data ...