Setting up and mastering radius search in PostgreSQL (9.1)


Radius search in PostgreSQL may come in employing a light and/or a much more sophisticated version. This article discusses the light one, namely the cube and the earth distance extensions, most probably sufficient for the web user’s getting here and there requirements. earth distance, depending on cube, assumes the earth to be perfectly spherical, anyone demanding a higher accuracy level, especially for the mountainous parts, may take a look at the PostGIS project.

Although radius search, the light variety, will be up fast and performing well, there may be some mantrap around, for the ones who prefer to read documentation the easy way too. First of all, PostgreSQL: Documentation: 9.1: earthdistance indicates that the point-based earth distance calculation is hard-wired to statute miles in units. You may use this circumstance to your advantage, like datachomp did in Radius Queries in Postgres, as long as you know what you’re doing. Second to that, taking on the alternate cube-based earth distance calculation, the earth_box function, accepting a lat/long and a radius on input, may return locations farther than the actual radius given (documented alike). This is because earth_box, as the name implies, still handles a box geometry on the idealized sphere (and not some higher order circle surface). But more on that below.

(more…)

Advertisements

Flashback version query and the proper use of timestamp and scn clauses


Flashback version query essentially enables you to lookup the incarnations of a row (defined by primary key) in the past, in a consecutive manner. Version information is depicted by a couple of pseudo-columns, namely versions_xid, versions_startscn, versions_endscn, versions_starttime, versions_endtime and versions_operation. See Using Oracle Flashback Version Query in the docs for explanations.

In combination with flashback query or flashback transaction query, one may restore a row incarnation from the past into a new table or even rollback to a past row incarnation within the same table.

This article will discuss flashback version query together with flashback query to restore one to many rows, just shown for a row of a unique key here for brevity, detailing when and when not to use timestamp and scn select where clauses to prevent pitfalls. An example table / dataset will be given, representing a real world scenario where some past data needs to be identified first and is then to be made available again.

Flashback version query uses the following pattern, including the pseudo-columns introduced above, on an actual application-, but not a system-table (alike flashback transaction query). A timestamp– or scn-range must be supplied to define the lookup window (defined by the stock of the available undo-data, remember) and to actually populate the pseudo-columns, respectively:

SELECT pseudo_col1, ..., app_col1, ... FROM app_tab
VERSIONS BETWEEN
  { SCN | TIMESTAMP } { expr | MINVALUE }
  AND { expr | MAXVALUE } ]

Flashback query then provides for the historic data selection in terms of application-table columns, typically used to run a create table as select..., if you like, supplying an as of timestamp– or scn selector:

-- CTAS, maybe
SELECT app_col1, ... FROM app_tab
  AS OF { SCN | TIMESTAMP } expr

All theory so far, yet the real example upfront, make shure have grasped what this trinity in fact means:

  • Flashback version query
  • Flashback query
  • Flashback transaction query

Also be prepared to unhesitantly get down to pen and paper when it comes to history lookup time windows and row level incarnations of data. It’s quite tricky and bewildering sometimes, be concentrated, have a sketch of timelines at hand (you know for https://en.wikipedia.org/wiki/Primer_(film), for example, some visualization like https://en.wikipedia.org/wiki/File:Time_Travel_Method-2.svg may come in very handy).

(more…)

Getting LauncherFolders up and running on Ubuntu 16.04.4


LauncherFolders (http://unity-folders.exceptionfound.com , https://itsfoss.com/group-apps-unity-launcher-launcherfolders) is a great extension to the unity launcher, in being lightweight abd shipping a lot of bang when it only comes to set up containers organizing your apps. However, obviously the code has been crafted back in the Ubuntu 14.04 era, leaving open issues for installation on more modern Ubuntu releases.

First of all, the official ppa (ppa:asukhovatkin/unity-launcher-folders) will no longer register successfully for security reasons such that one has to ressort back to the original deb installation medium (http://unity-folders.exceptionfound.com/unity-launcher-folders_1.0.3_all.deb).

The next fixes, run the app from the console to see the error messages, are documented in (https://askubuntu.com/questions/934916/ubuntu-launcher-folder-not-working) and (https://ubuntuforums.org/showthread.php?t=2325175 , comment #5):

sudo apt install python-gobject python-pil
gksudo gedit /usr/lib/python2.7/dist-packages/unity_launcher_folders/generateIcon.py
#17 change: "import Image" -> "from PIL import Image"

Getting this far, the app itself comes up and is operable as expected. Pity is but, that the folder pane does not show up when clicking the generated launcher item (though it worked in the preview mode). The launcher item itself is nothing more than some .desktop file in (~/.local/share/applications/Browser.desktop). On inspection, we have this exec entry:

Exec=/usr/share/unity-launcher-folders/drawer.py "/home/anyone/.appDrawerConfig/Browser.pickle"

Giving it another console output run reveals another missing python dependency:

(more…)

Grepping the actual bind values of sql through v$sql_bind_capture


Programmatically or intercepted by forced cursor sharing, sql where clause actual values shall always be bound to variable placeholders and never / no longer be literally coded. You know Tom Kyte talking that story on each and every occasion, pointing out that so many sql areas got stuck in size and performance because of literal values and the resulting multitude of variants of sql statements. On the other hand, people complain about the sporadic issue that the optimizer takes wrong decisions due to one-time probing of actual values in a given session, a nightmare in 10g, much improved by adaptive cursor sharing throughout 12c meanwhile. Well, I do not want to dive into this again, what follows is just a commented recipe sql statement to inspect what actual bind values have had been in action for a (potentially) sub-optimal sql execution. Please note, that the STATISTICS_LEVEL initialization parameter takes to be greater than BASIC to have the statement deliver any data.

The statement is neither complex nor long-running, just using two perfomance views v$sql_bind_capture and v$sqlarea, resp. While v$sql_bind_capture provides for the bind names, values, capture state and time, v$sqlarea offers different ways to approach the subject, by schema or sql-id or module etc, and not at least, the raw text of the statement in question.

(more…)

Oracle linux 7.x reboot systemd swap target timeout workaround


There is an issue around currently for Red Hat based systems, Oracle Linux here, in version 7.3. running systemd version 219-30.0.1, having a shutdown or reboot seemingly hang on a failed swap unit (deallocation). A lot of posts on the net discuss the issue, After switching to Ubuntu 15.04 laptop won’t shutdown suggested the w/a, doing a swapoff/swapon bounce in advance, that worked for me, referencing reboot hangs at ‘Reached target Shutdown’. Systemd: Hangs indefinitely on >90% of reboot attempts comprises in in-depth analysis.

I’m not shure, though, whether tmp.mount.hm4: After swap.target is releated, really, because the implemented change is already present on my systems (systemd‘s). I’m much more tending to suspect widespread storage fragmentation on the swap area to cause the relatively long term swap off run-times. In addition, I almost only experienced the issue for systems that have been up for a longer number of days, say from 90 days onwards.

(more…)