Oracle global temp tabs or nologging/append – saved redo in numbers

In an attempt to reduce redo entries (and archive space) generated for only temporarily computed contents of a couple of simple tables, I regarded employing Global Temporary Tables as well as Nologging Inserts as redesign options. This article, however, is not meant to dive into the details of these redesign options at all. There’s plenty of examples and discussions about the pros and cons of each option around the net. Most notably to mention, and a stimulus to post just my redo reduction test results, is Tim Hall’s compact articles on the subject like https://oracle-base.com/articles/misc/temporary-tables and https://oracle-base.com/articles/misc/append-hint that do include an assessment of the redo matter.

So, what’s the lineup for short? On startup, some data will be sourced throughout the database, losely computed and brutely written into a couple of simple tables. Then some third party will read this data for own purposes and will report completion such that the data can eventually be discarded completely. In making shure that an iteration step always starts unsoiled, any data left over from a crashed precursor will be rubbed out as well. Nobody cares about backups of this data, iteration management runs on other tables. You see, this is not really something that takes a database to complete successfully but…

Making up a chatty console screen on oracle enterprise linux 7

A lot of people, including me obviously, prefer to follow down the details of a boot process on a text console of oe linux. Unfortunaltely, populating such a detailed output is not the default setting after a fresh install of the operating system. You usually get a graphical boot progress animation, hiding most iff not all of the detail output, based on plymouth (rhgb). The boot screen dimension is another problem here, because following output on a 80×30 resolution is not fun kicking in. So where to start off? grub2, namely /etc/default/grub, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX, GRUB_CMDLINE_LINUX and some sort of update-grub I would think… but that’s wrong and even counter-productive for rh based distributions, really.

In fact, the integration of grub2 into oe linux is kind of different from the supposed picture given in https://www.gnu.org/software/grub/manual/html_node/index.html. That is, oe linux does not honour the variables being set with /etc/default/grub at all, GRUB_TIMEOUT being an exception on test, when recreating /boot/grub2/grub.cfg. There is no update-grub, like on debian likes, and moreover, do not use grub2-mkconfig -o /boot/grub2/grub.cfg, as recommended all around the net, on oe linux, because grub2-mkconfig may rewrite your kernel boot menue titles such that your default kernel setting may become stale (http://brainpan.io/wiki/Grub_2_Tips_%26_Tricks). Use grubby, see below.

Ok, instead of separating the grub2 boot variables in /etc/default/grub, oe linux derives any boot settings to be applied to a current kernel for reboot or most importantly for a new kernel on install from what is already present in /boot/grub2/grub.cfg for the running kernel. Its another approach, for whatever reason, like it or not. Changing the boot settings for the current kernel involves a script called grubby (https://www.mankier.com/8/grubby). Going for a kernel on install with yum executes the script new-kernel-package (https://www.mankier.com/8/new-kernel-pkg), which in turn again uses grubby under the covers. So what you need to make shure is that anything envisioned for modification or installation will already be present in /boot/grub2/grub.cfg. Check!