POUG and other plans.

September, October, November are just around the corner.

That means: Quickly sneak in some more motorcycle-riding before Winter sets in.

Early September I hope to ride this:



Edit: here is the link to the actual route:
https://myadventure.bike/trips/505

Edit2: And Here is the link to the ppt from POUG18.

Current plan is to go speak at four conferences this autumn:

POUG (6-9 Sept, Sopot, Northern Poland - the map above)
MakeIT2018  by SIOUG (14-16 Oct, Portoroz,  on the Adriatic)
HROUG (17-20 Oct, Rovinj, only 90min from Portoroz..).
DOAG (19-23 Nov, Nuremberg)

Optionally: PG-Day Europe in Lisbon.
Just after HROUG - would mean 3 days of solid riding between Venice and Lisbon. That sounds more romantic than it is, but still a Very Good Ride (Link to map)

Optionally: UKOUG Conference in Liverpool.
Early December. Not practical on a motorcycle. But possibly a last occasion to visit england before the dreaded brexit kicks in.


*** Insert logos and links here ***

*** Insert the Proud "I am a Speaker" stuff here ***

*** Insert oracle ace-stuff... Nah. ***


The real reason to visit these events is of course to do the "Road Trip", and to meet some interesting folks from the Database-world.

Hope to see you at some conferece soon.

Spring Trip via RigaDevDays and BGOUG

It is that time of year: Conferences on the horizon.

Edit: yesss. you can follow it Live on myadventure.bike, Right Here.
Or use Google, let me help..

My main items this spring are RigaDevDays (RDD link), Bulgaria Orace Usergroup Spring Conference (BgOUG link) and an evening at the Romanian RoOUG. Plus a few other planned visits of friends and places, meals and coffee on the way. I am kinda sorry to miss out on NL-OUG event and the Austrian OUG, but I will remember those for next year.

Here is the approximate map for this spring (I will probably avoid taking the same roads twice):

After this trip, later in the Summer and Autumn, I hope to do a few more trips if I can get papers accepted. I know that POUG (Poland, September) is near-certain, and I might re-visit Slovenia, Croatia and Germany if the schedule and the jury help a little.

Edit: As requested, I added the "Awesome Logos"...

Docker and PDB discussion

This blog-entry will serve as my note-taking and explanation-texts for a Docker discussion that started on Twitter on 30Mar2018.

Topic: Docker and PDBs

Questions:
Here are the key questions I want to ask "everybody", before we dive into discussion:
Q1: What kind of use-cases are developing out there for Oracle on Docker ?
Q2: What do you (all) want to do with OracleDB running from a Docker-container?
Q3: (Gerald?) What is the direction that Oracle wants to take with 18.x and PDBs on docker ?

More detailed questions tend to follow, but ... Later!

I am interested in your answers to Q1/Q2 before we start the detailed discussions, mainly to prevent my own "tunnel vision". I realise that Others have often very different views of products and possibilities. So let's hear it from you!



----- Space for Pause and Reflexion -------



Popssible agenda for discussion:
 - open for suggestions...
 - me: Use Docker to deploy Oracle-DB software, and plug various PDBs in/out.
(add your suggestions here...)

Docker:
 - Simple to deploy, clone-able.
 - Runs nearly anywhere.
 - Disposable containers, e.g. Cattle, stateless.
(add your items/suggestions.... )

Databases, and PDBs:
 - Storage of data (ACID), e.g. Pet, Stateful.
 - Application code-base in PL/SQL or similar (#SmartDB).
 - PDBs: Easy (re)start of dev sandboxes (including app-code in PL/SQL).
 - PDBs: Clone from prod/acc/test/pristine environments.
(add your items/suggestions)


Wishlist for OracleDB on Docker:
 - A quick-deploy method to many platforms (that it is already!)
 - A guaranteed, known, software version (e.g. known version + patches)
 - Image as light (small) as possible.
 - Complicated: Patching, First on a "golden" image (per project?), then distributed.

 - Nice-to-have: when oracle18 is out: Read-Only OH.
 - Clear choice of data: "in" or "outside" of the container (mappable volumes).

(add your items here...)

Background:

Gerald Venzl (link) has provided and published Docker Images (link) that can run an Oracle Database. There are also a range of other Oracle-provided containers that allow "devs" to play with various oracle tools, and I'm sure everyone is discovering various ways to use Docker.

In another universe someone (link to jk) even complained that Containers were used for "production databases". I'm really curious to see how+where+when that works, notably if the data is stored persistently, ACIDly, and how the additional layer from container-to-storage is affecting the running and performance.


Storage, persistence: 
I can see two distinct cases, your choice will depend on circumstances:
 - Data inside the container, and disposable. You can lose the data at some (unexpected?) point.
 - Data on mapped volumes, and Persistent. You have more control over the data.

In my case:
 - Disposable "sandboxes : can be in the container. But any plug/in/out may have to be done over DB-links, cumbersome.
 - Persistent data: mappable (host-)Volumes. Easy to reach, similar to NFS concept with pros/cons.


Notable items for Docker, from my memory/history:
 - Avoid splitting the database over "container" and "volumes".
 - Keep the spfiles and orapwfiles with the data (linked into the dbconfig in 12.2, nice!)
 - Also map diag-directory, prevent container-storage from filling up (was easy)
 - Detail: add a "vi" to the container. I had to yum it in.
 - Make perl catcon.pl work correctly or use bash. (I like CreateDB, not just dbca...)
( - add your items here...)


My own agenda (if any) is to have the OracleDB software in an easy-deploy, run-anywhere container, with the option to keep the data "external" and to plug-in PDBs at will.

My "containers" resemble old-fashioned VMs. Not sure if that is "correct way"

My deployed-container will be my "processing unit" and my "service".
The docker-host will provide storage as mappable volumes.
The concept I would use would resemble a set of linux-servers with an NFS for filesystem.

Side-topics, optional, later:
 - Anything Oracle can do to concentrate all "output files" to a small number of mountpoints is welcome. I used to spend time putting spfile, ctlfiles, redo, data, archives, log/diag all in 1 subdir-tree to allow easy movement of databases between systems. Gerald has mentioned FSH already: that was a good concept on unix once. All output to a "/var" subdir.
 - Anything Oracle can do to make (un)plug of containers easier: Welcome. I would like a PDB to be even more simple transportable from 1 subdir, including all files needed (oracle is close!). In another DB, all you do is provide some name, or point 1 (one) environment variable $QHDATA to 1 (one) subdir, and the whole DB materializes under it... Neat! No messing with "file-name-convert" or GUID/random strings. Easy, Flexible!


Open for Discussion... (on twitter?)


Copies of Relevant links:
Gerald : https://geraldonit.com/2017/08/21/creating-an-oracle-database-docker-image/
docker images : https://github.com/oracle/docker-images/tree/master/OracleDatabase

The tweet that started it. https://twitter.com/GeraldVenzl/status/979736165564661760

Rename user or Update SYS.USER$.NAME

Last week, someone mentioned "alter user rename" or similar quick-trick to modify a username. I think the link came through via Kevin Closson.
It reminded me of a very old and undocumented trick to just update the "name" in the  SYS.USER$. From ancient memory: I think this was used for some very old in-place upgrade in the 90s  once.

----------------------------------
Update: Martin Berger (@Martinberx) pointed out this blog by Dirk Nachbar on the same topic. Which Dirk has updated Here for 18c Seems an undocumented feature, but working.

Needless to say that everyone: Dirk, Martin, Kevin and AskTom, strongly Dis-recommend to play with the user$ table, as I am about to show you ...

-----------------------------------

Anyway, how could I resist a trivial test...?

*** Warning: Dont Do This on a Serious Database ***

(do this only if you are willing to scrap the database you try this on) 

*** You have been Warned ***

*** Please tick "accept"  etc... ***

For testing, I'm using the vagrant box from github.

https://github.com/oracle/vagrant-boxes

To test, I logon to the pluggable database ORCLPDB1 as SYS, and I create a user : U1.

I then rename it to U2 as follows:

Update sys.user$ set name = 'U1' where name = 'U1';

commit ;

Background : 

I would expect that the catalog stores the user-name nicely in 1 place, in the SYS.USER$.NAME.

What I learned (and please dont take undocumented hack this for Truth,... )

 - It may Just Work (but please dont...).

 - You need to at least flush the shared-pool, but a complete startup-force is probably advised after the update+commit.

 - You can end up with connections of non-existing users (hence a restart is a good idea).

For a Trivial schema+app it seems to work with just a flush-shared_pool to make the change come into effect. This makes +/- sense if you think about it.

Here is the test-script (link)

And the output (link).

Some of the Questions raised:

 - Is this method feasible at all? e.g. is the username really stored and retrieved consistently from the same field in the table sys.user$ ? 

 - Would this be feasible for rename of other objects as well (why bother? copy or re-create stmnts are equally efficient for most objects?)

 - what would happen if the schema to rename depended on others, or had others depend on it ? (if all references go over user_id and object_id: it may just work...)

Maybe Later, if the weather remains as is...

Do I have to repeat the "Do not use at home" disclaimer...?

Nah, you get it.