Update to myschema available!

Folks: I have uploaded an update to my utils2_ak package to my web site ( My Utilities ) with the following change: Fixed the --infrastructure output for PLOG type dbspaces to eliminate free space within the PLOG space that is an artifact of having moved the physical log within that dbspace at some point in the past. A new server built from the myschema infrastructure output does not need that storage wasted. Note that dbschema -c incorrectly produces a PLOG space that includes the wasted storage. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Okay Art and Community we're stumped; why would someone want to shrink a physical log within a plog space? If there's no good reason to do this we'll disallow it. TIA. ------------------------------ John Lengyel ------------------------------

Maybe you made a typo and allocated 20G instead of 2Gb - grasping at straws On 12/26/2024 2:54 PM, John Lengyel via IBM TechXchange Community wrote: 0100019404c0252f-81b945c2-d10b-4aeb-8f45-a3f72cb3c3bf-000000@email.amazonses.com"> Okay Art and Community we're stumped; why would someone want to shrink a physical log within a plog space? If there's no good reason to do this we...

Over half of my grasps involve straws... My hope is that in this case you'd create a new 2 GB plog space, which will automatically drop the old plog space, allowing you to reclaim that 20GB. If you shrink the plog from 20 GB to 2 GB within a plog space all you're doing is wasting 18 GB, since there's nothing else you can do with that space. No tables, no logical logs. Nada, unless you guys have figured out something crazy that I don't know about... ------------------------------ John Lengyel ------------------------------

JC: Real situation that a user texted me about this morning. They initialized the server with a 25MB physical log using the installer. Later they realized that they needed a bigger physical log. He thought that all he had to do is to set PHYSIZE and bounce the instance like we used to do in the old days to resize the log. But, of course, in v12.10 & 14.10 that doesn't happen so he had reached out to me to ask why if he created a 35.02GB physical log the message log was complaining that the log had filled up during a checkpoint and blocked transactions and that it was still only 25MB. Since, he argued, that onstat -d was showing that the physdbs had 35GB of free space how could it be filling?? Anyway I explained that they had to use onparams to resize the log in place or use onspaces to create a new PLOG space moving the log in there then drop the original physdbs. They chose to do the latter, as you recommended. However, out of curiousity I ran the onparams command to double my own physical log in the same plog space and found that when it was completed the size of the original log was free space in that dbspace. Running either dbschema -c or myschema --infrastructure both created command lines or API functions to create a PLOG dbspace that was to be sized the size of the dbspace rather than the size of the physical log! My take on using dbschema -c or myschema --infrastructure is that it is used when porting a server to a new host or even a new environment, so I want the target system to be created as close to the source instance as possible, and that means that I want the target physical log to be 20GB not 30GB! So, I "fixed" myschema to subtract the free space in the PLOG dbspace from the size. I think that dbschema should be likewise "fixed". Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

OH forgot, when he changed PHYSIZE he also used the API to extend the PLOG space from 25MB by an additional 30GB. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Got it. Thanks Art. I think we'll disallow shrinkage and we'll look at fixing dbschema -c as well. I agree that using the size of the plog space rather than that of the physical log (plus overhead) doesn't make sense. ------------------------------ John Lengyel ------------------------------

Yeah we should disallow that too. Internally extending the plog space's chunk in order to increase the size of the physical log? Fine. External extension? Doesn't make sense. Tx. ------------------------------ John Lengyel ------------------------------

Agreed. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------