Return
-
Title
OLR Wizard /xp_objectrecovery_viewcontents hangs. Failed to Read Objects to Recover: bad allocation -
Description
Extended stored procedure 'xp_objectrecovery_viewcontents' (what the OLR Wizard is running) hangs.We want to recover specific tables using LiteSpeed Object Level Recovery (OLR) wizard.We select about 80 tlog files from which to recover the tables. And after selecting the files and confirming the contents, we click on "finish" at the end of the Wizard, It does run for about 5 minutes but then ends with:"Failed to Read Objects to Recover: bad allocation".And so we never get to the Object Level Recovery screen where we can choose which tables to recover in 'Recover Table'.We need to be able to have OLR parse all our tlog backup files successfully so we can restore specific tables.Also, we ran this directly via a TSQL script to see if we would have success that way. When we were in the LiteSpeed OLR Wizard, on the 'Preview Script' screen, we copied that script to the SQL Server Management Console query window. And also added to that script these two below parameters:@LSM = N'Create'@LSMPath = N’<Path to lsm folder>’And before we executed it, we deleted any pre-existing LSM file that may be located in that LSM folder location.
The results of running it this way:LiteSpeed(R) for SQL Server Object Level Recovery 8.7.0.304Copyright 2018 Quest Software Inc. ALL RIGHTS RESERVED.Msg 60000, Level 16, State 1, Line 0bad allocationWe are able to succeed when using 63 tlog backup files. 64th, 65th and 66th tlog backups are of size 1.2, 5.9 and 1.5GB respectively. The size of all log files sums around 60GB.This server has total RAM of 48GB. And three SQL instances with max memory 12GB, 15GB and 3GB. This leaves 18GB to the OS and other processes such as LiteSpeed OLR. SQL instances using 63% of total RAM (close to recommended 70% max). After we lowered SQL Max Memory, we got further, to the 67th tlog. Total size of all these 67 files sums up to 10.6GB compressed at level 2.When we were monitoring closely, we identified that OLR took up more than 21GB of memory (peak load) while processing these 10.6 GB TLog backups. Why is OLR taking up this much memory? -
Cause
Product defect. The defect is that OLR takes up too much system memory at its peak memory usage, and hangs, when there are many large T-log files to process. There is no tracking number yet for this defect. -
Resolution
WORKAROUND
none
STATUSFixed in latest build of LiteSpeed version 8.8. (a newer build than the version 8.8 up on Supportlink). Contact Technical Support, ask for the latest build of version 8.8, and reference the knowledgebase article (309350). This build will allow you to get all the needed tlog files listed for the Object Level Recovery.
-
Defect ID
not available yet -
Additional Information
not related to KB 257856