Hi All,
We have an SAT environment in that the hashed files are already created in 32 BIT dynamic files. Today we changed the 32-bit into 64-BIT hashed files by changing the values in uvconfig file parameter: 64BIT_FILES 1. We have enough system space. we didn't do any other than this. But today while building the hashed files, the job(only 2 jobs) took 10 hours to complete. Normally this job took 2 hours to complete..Can you please suggest me what are the prerequisite while changing the 32-bit To 64-bit hashed file and also improving the performance. The rest of the hash building jobs ran normally.
Thanks & Regards,
Satheesh
prerequisite while Changing 32-bit To 64-bit Hashed File?
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 182
- Joined: Thu Jun 16, 2005 2:05 am
Bad Idea. If that's something a search here turned up, it should have also revealed many caveats for enabling that option.
You have now made every hashed file 64bit. All of them - in your Projects, in the DSEngine, everywhere. You should change individual hashed files and only the ones that need it.
You have now made every hashed file 64bit. All of them - in your Projects, in the DSEngine, everywhere. You should change individual hashed files and only the ones that need it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 182
- Joined: Thu Jun 16, 2005 2:05 am
Hi,
But the hashed job that designed by using the create option delete file before create can be converted into 64 BIT , but the above option doesn't used job are not converted into 64BIT....is this result that the jobs(using above option) took much longer time than normal....any other things can be taken care.....please advice..
Thanks & Regards,
Satheesh
But the hashed job that designed by using the create option delete file before create can be converted into 64 BIT , but the above option doesn't used job are not converted into 64BIT....is this result that the jobs(using above option) took much longer time than normal....any other things can be taken care.....please advice..
Thanks & Regards,
Satheesh
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Reset 64BIT_FILES to zero and restart DataStage. As Craig said, to set this to 1 is a Bad Idea. Prefer to issue your own CREATE.FILE or mkdbfile commands to create 64-bit hashed files, but only when necessary. You can get the syntax from the Hashed File Calculator (on your DataStage CD).
64-bit hashed files have a 24 byte overhead (three eight-byte pointers) per record stored, or 40 bytes (five eight-byte pointers) if the record size is bigger than LARGE.RECORD. 32-bit hashed files have only half of this overhead.
You can use RESIZE to convert existing hashed files to 64-bit operation.You may need first to create a VOC entry for the hashed file, using SETFILE. Discussion of both these commands will be revealed by searching the forum.
Before doing any of this, however, consider whether you are not wasting space in the hashed file. Do you load any rows that you never look up? Do you load any columns that are never used in any job? Eliminating these might bring the overall size of the hashed file below the size at which internal 64-bit addressing is needed.
64-bit hashed files have a 24 byte overhead (three eight-byte pointers) per record stored, or 40 bytes (five eight-byte pointers) if the record size is bigger than LARGE.RECORD. 32-bit hashed files have only half of this overhead.
You can use RESIZE to convert existing hashed files to 64-bit operation.
Code: Select all
RESIZE hashedfile * * * 64BIT USING /pathname
Before doing any of this, however, consider whether you are not wasting space in the hashed file. Do you load any rows that you never look up? Do you load any columns that are never used in any job? Eliminating these might bring the overall size of the hashed file below the size at which internal 64-bit addressing is needed.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 182
- Joined: Thu Jun 16, 2005 2:05 am