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.

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.

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...

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.

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

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...

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.

OH forgot, when he changed PHYSIZE he also used the API to extend the PLOG space from 25MB by an additional 30GB.

Art

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

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...

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.

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.

OH forgot, when he changed PHYSIZE he also used the API to extend the PLOG space from 25MB by an additional 30GB.

Art

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

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...

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.

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

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...

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.