This Log Buffer Edition brings you some blog posts from Oracle, SQL Server and MySQL.

Oracle:

Suppose you have a global zone with multiple zpools that you would like to convert into a native zone.

The digital revolution is creating abundance in almost every industry—turning spare bedrooms into hotel rooms, low-occupancy commuter vehicles into taxi services, and free time into freelance time

Every time I attend a conference, the Twitter traffic about said conference is obviously higher.  It starts a couple weeks or even months before, builds steadily as the conference approaches, and then …

In Mo’ Data, Mo’ Problems, we explored the paradox that “Big Data” projects pose to organizations and how Tokutek is taking an innovative approach to solving those problems. In this post, we’re going to talk about another hot topic in IT, “The Cloud,” and how enterprises undertaking Cloud efforts often struggle with idea of “problem trading.” Also, for some reason, databases are just given a pass as traditionally “noisy neighbors” and that there is nothing that can be done about it. Lets take a look at why we disagree.

With the birth of the information age came a coupling of business and IT. Increasingly strategic business projects and objectives were reliant on information infrastructure to provide information storage and retrieval instead of paper and filing cabinets. This was the dawn of the database and what gave rise to companies like Oracle, Sybase and MySQL. With the appearance of true Enterprise Grade …

During the process of reviewing our server defaults for MySQL 5.7, we thought that it might be better to change the default transaction isolation level from REPEATABLE-READ to READ-COMMITTED (the default for PostgreSQL, Oracle, and SQL Server). After some benchmarking, however, it seems that we should stick with REPEATABLE-READ as the default for now.

It’s very easy to modify the default isolation level, however, and it can even be done at the SESSION level. For the most optimal performance you can change the transaction isolation level dynamically in your SESSION according …

System QA took the approach of using Random Query Generator (RQG)  to generate different SQL’s for multitude of data types available and supported in MySQL.

This approach would help in easily testing the validity of currently supported data types and changes (if any) to the same.

Following steps explain What and How this was accomplished

1. Generate the table structure and generate insert queries for different data types through RQG and redirect to a file.
   
   Use gendata.pl which is part of RQG to create Table structure ( for this instance we have used DATE related data type )
   
   $ perl gendata.pl --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=rqg --spec=ex_dt.zz
   
   
2. Generate SQL queries using gensql and redirect the output to a file
   
   For the …

MySQL introduced the Event Scheduler in version 5.1.6. The Event Scheduler is a MySQL-level “cron job”, which will run events inside MySQL. Up until now, this was not a very popular feature, however, it has gotten more popular since the adoption of Amazon RDS – as well as similar MySQL database as a service offerings where there is no OS level.

What is important to understand about the Event Scheduler is that it does not have any protection against multiple execution (neither does linux cron). Let’s imagine you have created an event that executes every 10 seconds, but the logic inside the event (i.e. queries or stored procedure call) can …

We recently deployed multiple new pages at VividCortex providing detailed query and metric information. To access this level of information previously, you had to utilize Top Queries, one of our most popular tools. While the power of Top Queries lies in the ability to rank queries by specific criteria, these new pages allow users to easily filter and see detailed information about any query or metric.

VividCortex provides industry-leading, one-second granularity to provide unparallelled visibility into the work being done on your database systems. We track thousands of metrics from the database and operating system, providing you with actionable analysis through our innovative tools. When you deal with this much information, simplicity is a priority. Both of these new tools are simple to use but provide a tremendous amount of data.

Selecting Queries or Metrics in the left-hand …

Following on from my two earlier posts, in the MySQL team we are proposing a new set of changes to defaults for MySQL 5.7:

default_tmp_storage_engine variable was introduced in 5.6.3, allowing the configuration of the default engine for temporary tables. This seems to be in the direction, as I commented before, of making MyISAM an optional engine. In 5.7, a separate tablespace is being created to hold those tables in order to reduce its performance penalty (those tables do not need to be redone if the server crashes, so extra writes are avoided).

However, I have seen many people assuming that because default_tmp_storage_engine has the value “InnoDB”, all temporary tables are created in InnoDB format in 5.6. This is not true: first, because implicit temporary tables are still being created in memory using …

MySQL’s innodb_file_per_table is a wonderful thing – most of the time. Having every table use its own .ibd file allows you to easily reclaim space when dropping or truncating tables. But in some use cases, it may cause significant performance issues.

Many of you in the audience are responsible for running automated tests on your codebase before deploying to production. If you are, then one of your goals is having tests run as quickly as possible so you can run them as frequently as possible. Often times you can change specific settings in your test environment that don’t affect the outcome of the test, but do improve throughput. This post discusses how innodb_file_per_table is one of those settings.

I recently spoke with a customer whose use case involved creating hundreds of tables on up to 16 schemas …

There’s no such thing as a schemaless database. I know, lots of people want a schemaless database, and lots of companies are promoting their products as schemaless DBMSs. And schemaless DBMSs exist. But schemaless databases are mythical beasts because there is always a schema somewhere. Usually in multiple places, which I will later claim is what causes grief.

There Is Always A Schema

We should define “schema” first. It comes from Greek roots, meaning “form, figure” according to my dictionary. Wikipedia says, roughly,

A database schema is its structure; a set of integrity constraints imposed on a database. These integrity constraints ensure compatibility between parts of the schema.

In other words, a schema expresses expectations about what fields exist in a database, and what their types will be. It also enforces those expectations, at least to some extent (there’s usually some …