Fix_LH

Comments

• DonBakke

  March 11

  I don't know. You could create a profile log and get a good insight into the various routines that get called. Then you might be able to use that and create a workflow process for Fix_LH.
• Michael

  March 29

  Hola all,
  
  The conventional wisdom among some of the "old-timers" with my client is that FIX_LH can actually be run while a table is in use. I know that RTI_MAKETABLE absolutely cannot, and I thought FIX_LH was the same. Does anyone know if FIX_LH, especially the compress function, can be used while a table is being accessed?
  
  Gracias! And Happy Easter!
• DonBakke

  April 1

  Without endorsing the practice, FIX_LH can be used on a live table because it works on the groups that have problems (like a surgical strike) and doesn't do anything to the overall structure of the table itself. I don't know about the safety of using the compress function on a live table. My gut tells me it should also work because it is just reorganizing frames, which is what Linear Hash is capable of doing anyway. I would expect access to the table to be slow during this process.
  
  RTI_MAKETABLE creates a new table and copies the rows from the old one. This is why it can't be used on a live table.
• Michael

  August 5

  Back gnawing on this bone. I'm developing a process to archive or purge a lot of data (20 years' worth). The purge will not be a problem; but I know afterward the tables purged will be "flabby" (lots of wasted space). Plan A was to use RTI_Remaketable to remake the tables, but that will require a lot of impossible down-time. Using Fix_LH to compress will not get as great results, but it will be way better that if not.
  
  How/can I be sure that using Fix_LH will be ok on a table that's currently in use?
  
  Thanks!
  
  Michael
• Michael

  August 5

  So trying out the theory.. Fix_LH doesn't seem to work at all. It returns an error code of FS.
  
  Anyone run into this? Is there a workaround?
  
  Thanks!
• JaredBratu

  August 8

  Michael, There was a KB article about FS255 being reported on repair but I can't find it anymore.
  
  Ensure the application’s repair tables are attached. Not the SYSPROG versions, but the application repair tables:
  1. DUMP_FIX_GARBAGE
  2. DUMP_FIX_TEMP
  3. DUMP_FIX_SAVE
  
  If the SYSPROG versions are attached or the application versions aren't attached, then FS255 will appear when trying to repair.
• Michael

  August 8

  Thanks Jared.. If I can get it working, can it be run while the tables are in use?
  
  Other option is to run RTI_REMAKETABLE, which will Not work while in use.
  
  Thanks!
• JaredBratu

  August 8

  If I recall correctly running a repair on table that is in use - especially heavy use - can result in false GFEs because the groups can change while the scan for errors is running. For best results I take the table offline and repair it in local mode or in a separate copy of OpenInsight where only the repair process is accessing it.
  
  I don't have any experience using RTI_REMAKETABLE to repair GFEs.
  
  Another common option is to take the table offline, do a latent select and readnext through it - ignore any read errors, and then copy the rows it could read to a new clean table. I suppose you could do this while the table is online but you need to sizelock the table before doing this otherwise the latent select / readnext loop could be interrupted if the table is update while the readnext is running.
• Michael

  August 8

  The problem isn't GFE's. I need to compress the tables. I'm archiving 20+ years of data and the tables will need compressing badly. They actually already do.