Big Endian and Little Endian operating systems

Did you ever wonder or need to know which systems use big endian and which ones use little endian? Look no further, you can query it right out of the Oracle database:

SQL> SELECT platform_name, endian_format
FROM V$TRANSPORTABLE_PLATFORM
ORDER BY PLATFORM_NAME;
PLATFORM_NAME ENDIAN_FORMAT
AIX-Based Systems (64-bit) Big
Apple Mac OS Big
Apple Mac OS (x86-64) Little
HP IA Open VMS Little
HP Open VMS Little
HP Tru64 UNIX Little
HP-UX (64-bit) Big
HP-UX IA (64-bit) Big
IBM Power Based Linux Big
IBM zSeries Based Linux Big
Linux IA (32-bit) Little
Linux IA (64-bit) Little
Linux x86 64-bit Little
Microsoft Windows IA (32-bit) Little
Microsoft Windows IA (64-bit) Little
Microsoft Windows x86 64-bit Little
Solaris Operating System (x86) Little
Solaris Operating System (x86-64) Little
Solaris[tm] OE (32-bit) Big
Solaris[tm] OE (64-bit) Big

Why you should never put objects into the SYSTEM or SYSAUX tablespace

Just because you can doesn’t mean you should

I still see it happening that people put object, i.e. tables, etc. in the SYSTEM or SYSAUX tablespace. Sometimes it’s done deliberately, sometimes it happens automatically by creating a table in the SYS schema. Well, let me tell you, it’s a really bad idea. You should never, ever, ever put any kind of user object into those tablespaces. Even the Oracle Database Documentation warns you of doing so:

7.3.1 SYS and SYSTEM Users

The SYS and SYSTEM administrative user accounts are automatically created when you install Oracle Database. They are both created with the password that you supplied upon installation, and they are both automatically granted the DBA role.

  • SYS: This account can perform all administrative functions. All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by the database. They should never be modified by any user or database administrator. You must not create any tables in the SYS schema.The SYS user is granted the SYSDBA privilege, which enables a user to perform high-level administrative tasks such as backup and recovery. 
  • SYSTEM: This account can perform all administrative functions except the following:
    • Backup and recovery
    • Database upgrade

    While you can use this account to perform day-to-day administrative tasks, Oracle strongly recommends creating named user accounts for administering the Oracle database to enable monitoring of database activity.

The simplest explanation is that those tablespaces are Oracle internal tablespaces. They are there for Oracle to do its job, not for the user to store his data. However, Oracle doesn’t stop you from not doing so and that is mainly because of legacy/upgrade reasons. That’s right, there are still people out there happily running very, very old Oracle database versions and some of those old versions didn’t have the concept of system and user tablespaces back then. In order to allow a smooth(er) upgrade to a newer version Oracle still provides you the possibility to upgrade to the newer version, having your data in what would then become a system tablespace, and then move your tables and data over into user tablespaces after the upgrade is finished.

All that said, there are other legitimate, less well documented reasons why you should never put object into those tablespaces:

  • The SYS and SYSTEM tablespaces cannot be transported cross-endian (e.g. HP-UX (big endian) to Linux (small endian)), so if you want to migrate you will have lots of extra work to do.
  • Data Pump (and even back to original exp/imp) do not export SYS-owned objects, or even grants on SYS-owned objects, because doing so would open up lots of security problems.
  • Putting application or user objects in SYS or SYSTEM means granting access to those schemas (probably) that would not be appropriate for most applications or users. Or, to void that, it’s a lot more work to manage access to objects at an individual object level.

I hope this list helps and if anybody ever walks up to you, or you decide that it would be a good idea, please point them to this blog post and if they still don’t believe it, have them come talk to me.

Creating an Oracle Database Docker image

Run your Oracle database inside a Docker container

Oracle_Docker

Oracle has released Docker build files for the Oracle Database on Github. With those build files one can go ahead and build his or her own Docker image for the Oracle Database. If you don’t know what Docker is you should go and check it out. It’s a cool technology based on the Linux containers technology that allows you to containerize your application, whatever that application may be. Naturally, it didn’t take long for people to start looking at containerizing databases as well which makes a lot of sense, especially for, but not only, development and test environments. Here is a detailed blog post on how to containerize your Oracle Database by using those build files that Oracle has provided.

Continue reading “Creating an Oracle Database Docker image”

Disable SELinux on Oracle Linux 7

Sometimes when I want to test something or write a prototype of some sort SELinux (Security-Enhanced Linux) kicks in and hinders me, given that it is enabled by default on OL 7 UEK 4. STOP! Before I let you continue to read take a mental note of my disclaimer: I am an advocate of having security turned on by default. It helps us provide better and obviously more secure systems which, in turn, helps the world save time and money. Security should never, ever be turned off for production systems!
With this being said, here are a couple of quick steps for how to get around it.

tl;dr

  • setenforce 0
  • vim /etc/sysconfig/selinux
  • SELINUX=permissive

Here is also a short video on this topic:

Continue reading “Disable SELinux on Oracle Linux 7”