Forum Discussion

Korbyn's avatar
Korbyn
Level 5
14 years ago

EV SQL DB maintenance error

Been noticing in the sql maintenance logs the following error, and repeats it 3 times:

Rebuild Index (EVSQL1-SEVDB02\PRODSQL2)
Rebuild index on Local server connection
Databases: EVVSEVSERVeVS_3,EVVSEVSERVfVS_5,EVVSEVSERVgVS_6
Object: Tables and views
Original amount of free space
Task start: 2011-01-31T11:58:01.
Task end: 2011-01-31T11:58:01.
Failed:(-1073548784) Executing the query "ALTER INDEX [PK_HoldData_1] ON [dbo].[HoldData] REBUILD WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, ONLINE = ON )
" failed with the following error: "Online index operation cannot be performed for index 'PK_HoldData_1' because the index contains column 'HoldMetadata' of data type text, ntext, image, varchar(max), nvarchar(max), varbinary(max) or xml. For non-clustered index the column could be an include column of the index, for clustered index it could be any column of the table. In case of drop_existing the column could be part of new or old index. The operation must be performed offline.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
 

We're running EV 8.0 SP4 with SQL2005 SP3 on Windows 2003 R2 SP2 x64 machines.  And were following the maintenance tasks as defined in: http://www.symantec.com/business/support/index?page=content&id=TECH74666&actp=search&viewlocale=en_US&searchid=1291302398677

SQL is in a cluster, so is EV, not that it should matter much... 

  • There's nothing *to* resolve though, for the most part the SQL databases that EV use, whether its the Directory, Vault Store or Fingerprint, are normalized databases, with many indexes, primary keys, foreign keys, constraints, stored procedures, views, user defined types etc etc.

    So where as you can say its a result of how the database is designed, I would agree with you except this is not a negative, for the databases to be as performant as they are, there really isn't any other choice.


    Asking them to resolve an issue that quite clearly sits with SQL Server is like asking Symantec not to write indexes or DVS files that would cause fragmentation on the drive, its just not possible as its handled by Windows and the storage technology itself, and its the same way with SQL indexes becoming fragmented, its just part and parcel that goes with databases and their maintenance


    If you actually Google the message that you are getting, you will find thousands of results, such as
    http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/623d635e-94c7-4cdd-80f5-b46ab17cbbde

    or
    http://blog.sqlauthority.com/2007/08/17/sql-server-2005-explanation-and-script-for-online-index-operations-create-rebuild-drop/

    I guess my point is that you can't take what is pretty much SQL 101 for a regular DBA and have EV support perform that function for you, because there are many instances where a good DBA can make sure that your databases are integral and performant, just as a SAN Admin can make sure you have the correct and performant storage solutions for your needs, or your networking team can make sure your network is optimized etc, none of those functions should be expected to be replaced by a vendors support.







     




     

15 Replies

  • I'm not sure how much EV support will be able to do with it being a SQL issue and all

    You have several options really

    use DBCC DBReindex
    http://msdn.microsoft.com/en-us/library/ms181671(SQL.90).aspx

    Change your maintenance plans so that the index rebuild state does not require to keep the index online, for example
    ALTER INDEX [indexName] ON [dbo].[tableName] REBUILD WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, ONLINE = OFF )

    Another option maybe to use IndexOptimize by Ola Hallengren
    http://ola.hallengren.com/

  • Except its a SQL issue as a result of EV coding for the DB.  They've spent so many years building these DB's, tables and stored procedures, that I would expect Symantec to resolve this type of problem.  And IF the PLL being left on is accidental, then is should be Symantec to resolve it.

  • There's nothing *to* resolve though, for the most part the SQL databases that EV use, whether its the Directory, Vault Store or Fingerprint, are normalized databases, with many indexes, primary keys, foreign keys, constraints, stored procedures, views, user defined types etc etc.

    So where as you can say its a result of how the database is designed, I would agree with you except this is not a negative, for the databases to be as performant as they are, there really isn't any other choice.


    Asking them to resolve an issue that quite clearly sits with SQL Server is like asking Symantec not to write indexes or DVS files that would cause fragmentation on the drive, its just not possible as its handled by Windows and the storage technology itself, and its the same way with SQL indexes becoming fragmented, its just part and parcel that goes with databases and their maintenance


    If you actually Google the message that you are getting, you will find thousands of results, such as
    http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/623d635e-94c7-4cdd-80f5-b46ab17cbbde

    or
    http://blog.sqlauthority.com/2007/08/17/sql-server-2005-explanation-and-script-for-online-index-operations-create-rebuild-drop/

    I guess my point is that you can't take what is pretty much SQL 101 for a regular DBA and have EV support perform that function for you, because there are many instances where a good DBA can make sure that your databases are integral and performant, just as a SAN Admin can make sure you have the correct and performant storage solutions for your needs, or your networking team can make sure your network is optimized etc, none of those functions should be expected to be replaced by a vendors support.







     




     

  • What I meant JW, is that IF Symantec designed the table, view or what ever to have that Lock in place, then we should be deselecting the "Keep online..." option.

    However, if it's accidental that the Lock is in place, I can only believe it to be a result of the installation process or upgrade process, as half the guys say that it may be.

  • ah yeah, gotcha, sorry, the Page Level Locking has zero to do with this, its due to the data types and foreing keys used