I recently stubmbled upon this website that hosts a publicly available Oracle RDBMS instance running Oracle v2.3.2, which according to this Wikipedia article is the first commercially available version of Oracle. This version is not written in C, but in PDP-11 assembly. The website also has the manuals available. At this time the company was called Relational Software Incorporated or RSI for short, which they later renamed to Oracle Systems Corporation and then to Oracle Corporation. Before this the company was called Software Development Laboratories (SDL). Let’s have a quick look at this and see how it compares with newer versions. This version uses “UFI”, the predecessor of SQL*Plus. Let’s first create a table SQL>CREATE TABLE T1 SQL>ID(NUMBER NONULL UNIQUE IMAGE), SQL>NAME(CHAR(20) NONULL) SQL>/ Table created. And let’s do the same with Oracle 26ai SQL> CREATE TABLE T1 ( 2 ID NUMBER PRIMARY KEY, 3 NAME CHAR(20) NOT NULL 4 ) 5 / Table created. ...

Oracle recently announced a new authentication plugin: caching_sha2_password . This was added in 8.0.4 , the second release candidate for MySQL 8.0. The new plugin is also made the default (can be configured by changing default_authentication_plugin . Why? Phasing out SHA1 As Oracle said in the blog post to annouce this change they want to move to a more secure hashing algorithm ( SHA256 ). Which I think is a good reason to do this. Adding salt Adding a salt makes hashes for identical passwords, but different users different. Again a good reason to do this. Performance Their earlier attempt at this resulted in sha256_password . But this resulted in slower authentication. Without using persistent connections this is a serious limitation. So again a good reason. What's wrong? If you don't use SSL/TLS it gives your password away. To protect against sending the password in cleartext over an insecure connection it encrypts the password before sending it. It does this by ...

The issue On 12 September 2016 (three days ago) a MySQL security vulnerability was announced. The CVE id is CVE-2016-6662 . There are 3 claims: By setting malloc-lib in the configuration file access to an OS root shell can be gained. By using the general log a configuration file can be written in any place which is writable for the OS mysql user. By using SELECT...INTO DUMPFILE... it is possible to elevate privileges from a database user with the FILE privilege to any database account including root. How it is supposed to be used Find an SQL Injection in a website or otherwise gain access to a MySQL account. Now create a trigger file (requires FILE privilege) Now in the trigger or otherwise use SET GLOBAL general_log_file etc to create a my.cnf in the datadir with the correct privileges. Directly using SELECT...INTO DUMPFILE...won't work as that would result in the wrong permissions, which would cause mysqld/mysqld_safe to ignore that file. Now wait someone/somethi...

The next MySQL User Group NL meetup is this Tuesday at the Oracle office in Utrecht. For more info go to the Event page @ Meetup.com

According to the Oracle website the following certifications are available for MySQL: Oracle Certified Associate, MySQL 5.0/5.1/5.5 Oracle Certified Professional, MySQL 5.0 Developer Oracle Certified Professional, MySQL 5.0 Database Administrator Oracle Certified Expert, MySQL 5.1 Cluster Database Administrator There were two new versions released since MySQL 5.0. MySQL 5.0 was released in 2005, that's more than 5 years ago. And "MySQL 5.1 Cluster Database"? According to wikipedia the NDB release in the 5.1 source tree is old and not maintained. And Cluster 7.1 has many new features like multithreaded data nodes and disk based data. So Oracle, please update the certifications.