Upgrade Bigfix Version to 9.1.1117.0

system · July 15, 2014, 12:00am

(imported topic written by MBARTOSH)

We are planning to upgrade Bigfix from 8.2.1409.0 to 9.1.1117.0 this coming Wednesday night 7/16. Has anyone heard of any issues with the upgrade process or this version in general? Do you know of any reason we should not upgrade to this version?

system · July 21, 2014, 11:17pm

(imported comment written by sdemonte)

Just wondering…

How did your update go? Are you seeing the same, better or worse performance levels with FillDBPerf and the BufferDir processing?

Thanks,

Scott

system · July 23, 2014, 8:27am

(imported comment written by MBARTOSH)

We ended up canceling the upgrade because it was going to be more painful than we had hoped, and since we have a lot going on right now, we couldn’t afford to deal with upgrade issues.

Here is information I got from support.

The registrationlist file which tracks client registrations in the deployment will be migrated from a file based list on the server into the database. During this operation, what could happen is that it might cause all the clients in the deployment to reset themselves and send up full reports. So you may see many duplicate computers in your deployment. appear in the console. These can be cleared out (later on) using the Computer Remover tool. When the clients reset themselves they also send up full reports to the server containing a full set of their client data. This could cause a backlog on the relays and the server over the course of about a day (depending on how large your deployment is). Which means that many of your clients may start to appear as offline (gray) in the console until the backlog has had a time to catch up. Any new actions may take a while to report a status as well.

It has also been observed in some instances that during upgrading from 8 to 9, that the upgrade may cause some index fragmentation within the database. After the upgrade completes if you notice the sqlsrv process using a lot of CPU, you may want to run an offline index rebuild, here are the steps and the query to do this:

Stop All BES Services on the server
Backup the database
Run the offline rebuild index query in the database (see below) [15 min to and hour to complete, possibly longer depending on size of database]
Reboot the server machine

use BFEnterprise

declare table_cursor cursor for

select TABLE_SCHEMA, TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = ‘BASE TABLE’

open table_cursor

declare @tableName sysname

declare @tableSchema sysname

fetch next from table_cursor into @tableSchema, @tableName

while @@fetch_status != -1

begin

    if @tableName = 'ACTIONRESULTS'



    begin



            exec sp_indexoption 'ACTIONRESULTS.IX_Sequence', 'AllowPageLocks', TRUE



            exec sp_indexoption 'ACTIONRESULTS.IX_CID_AID',  'AllowPageLocks', TRUE



            exec sp_indexoption 'ACTIONRESULTS.IX_AID_CID',  'AllowPageLocks', TRUE



    end



    if @tableName = 'FIXLETRESULTS'



    begin



            exec sp_indexoption 'FIXLETRESULTS.pk_fixletresults', 'AllowPageLocks', TRUE



            exec sp_indexoption 'FIXLETRESULTS.IX_CID',                'AllowPageLocks', TRUE



            exec sp_indexoption 'FIXLETRESULTS.IX_Sequence',      'AllowPageLocks', TRUE



    end



    if @tableName = 'QUESTIONRESULTS'



    begin



            exec sp_indexoption 'QUESTIONRESULTS.pk_questionresults', 'AllowPageLocks', TRUE



            exec sp_indexoption 'QUESTIONRESULTS.IX_CID',             'AllowPageLocks', TRUE



            exec sp_indexoption 'QUESTIONRESULTS.IX_Sequence',        'AllowPageLocks', TRUE



    end






    execute ( N'alter index all on ' + @tableSchema + N'.' + @tableName + N' rebuild' )


   



    if @tableName = 'ACTIONRESULTS'



    begin



            exec sp_indexoption 'ACTIONRESULTS.IX_Sequence', 'AllowPageLocks', FALSE



            exec sp_indexoption 'ACTIONRESULTS.IX_CID_AID',  'AllowPageLocks', FALSE



            exec sp_indexoption 'ACTIONRESULTS.IX_AID_CID',  'AllowPageLocks', FALSE



    end



    if @tableName = 'FIXLETRESULTS'



    begin



            exec sp_indexoption 'FIXLETRESULTS.pk_fixletresults', 'AllowPageLocks', FALSE



            exec sp_indexoption 'FIXLETRESULTS.IX_CID',                'AllowPageLocks', FALSE



            exec sp_indexoption 'FIXLETRESULTS.IX_Sequence',      'AllowPageLocks', FALSE



    end



    if @tableName = 'QUESTIONRESULTS'



    begin



            exec sp_indexoption 'QUESTIONRESULTS.pk_questionresults', 'AllowPageLocks', FALSE



            exec sp_indexoption 'QUESTIONRESULTS.IX_CID',             'AllowPageLocks', FALSE



            exec sp_indexoption 'QUESTIONRESULTS.IX_Sequence',        'AllowPageLocks', FALSE



    end        


   



    fetch next from table_cursor into @tableSchema, @tableName

end

close table_cursor

deallocate table_cursor

The registrationlist file which tracks client registrations in the deployment will be migrated from a file based list on the server into the database. During this operation, what could happen is that it might cause all the clients in the deployment to reset themselves and send up full reports. So you may see many duplicate computers in your deployment. appear in the console. These can be cleared out (later on) using the Computer Remover tool. When the clients reset themselves they also send up full reports to the server containing a full set of their client data. This could cause a backlog on the relays and the server over the course of about a day (depending on how large your deployment is). Which means that many of your clients may start to appear as offline (gray) in the console until the backlog has had a time to catch up. Any new actions may take a while to report a status as well.