This article, part three of a three-part series, explores a DBAs journey to APEX.

The frenetic pace of application development in modern IT organizations means it’s not unusual to demand an application be built with minimal requirements gathering – literally, from a napkin-based sketch – to a working first draft of the app within extremely short time frames – even a weekend! – with production deployment to follow just a few days later. This article – the third in this ongoing series – demonstrates how simple it is to improve a basic prototype of the existing APEX application as well as construct a simple yet functional application for volunteer canvassers to connect with registered voters in a huge northwest suburban Chicago voting district, right from their mobile devices. Missed Part 2? Catch up here first.

Recent years have shown an upshift of open source technologies with an evident increase in hybrid applications from licensed and proprietary tools. One such popular technology is Python programming language, which has made its way to the top. Most of its popularity can be attributed to the variety of options it provides for visualization and machine learning alongside the application development and automation. This article will primarily focus on how Python’s graphing libraries can be used to understand data from a database administrator’s (DBA’s) perspective.

The frenetic pace of application development in modern IT organizations means it’s not unusual to demand an application be built with minimal requirements gathering – literally, from a napkin-based sketch – to a working first draft of the app within extremely short time frames – even a weekend! – with production deployment to follow just a few days later. This article – the second in this ongoing series – focuses on how easy it is to leverage Oracle APEX to build the first of several components of a sufficiently-robust application for election canvassers to identify, classify, and inform voters in a huge northwest suburban Chicago voting district.

This article explains how to configure Oracle API Gateway as a cluster on Solaris SPARC. The software can be download from the Oracle Technology Network. Before installing the API Gateway, you need to consider which components you require. Some components — for example, API Gateway Analytics — have additional requirements, such as a database. There are different components that could be installed, too, such as Policy Studio. There is not much documentation that discusses how to configure the Cluster for this product, so I chose to write one and be the first. The version of the API Gateway used in this article is Release 11.1.2.4.0, which is the latest at the time of writing.

This article, part one of a three-part series, explores a DBAs journey to APEX.

The frenetic pace of application development in modern IT organizations means it’s not unusual to demand an application be built with minimal requirement gathering—literally, from a napkin-based sketch—to a working first draft of the app within extremely short time frames—even a weekend!—with production deployment to follow just a few days later.
This article – the first in a series – demonstrates a real-life application development scenario: the creation of a mobile application that gives election canvassers a tool to identify, classify and inform voters in a huge suburban Chicago voting district – using the latest Oracle application development UI, data modeling tools, and database technology. Along the way, we’ll show how Oracle APEX makes short work of building a working application while the Oracle DBA leverages her newest tools—SQL Developer and Data Modeler—to build a secure, reliable, scalable application for her development team.

There are several methods used and developed over the years/decades since the Oracle Database has been around to migrate or clone your databases. Most of the methods have required us to use Data Guard or GoldenGate to achieve the same with minimal downtime or RMAN Backup files/Database Datafiles for regular cloning.

With the 12cR1 version of the database, remote cloning was introduced but still required to place the source non-CDB or PDB into Read-Only mode before initiating the cloning. With 12cR2, one has the ability to clone a database (also known as hot-cloning) without the restriction of read-only or downtime on the source. Also, hot-cloning can be achieved without an existing backup of the source.

We’ve all been there. When the rubber meets the road, it seems like the database, operations and development teams are never quite in-sync. No matter how thoroughly executed, tested, documented and validated, something in the production environment is never quite the same as the lower environments – be it a hardware inconsistency, a code mismatch, or even the dreaded typoed command. To add insult to injury, code always seems to change between the time it leaves a developer’s laptop and when it is deployed to a mission-critical system.
Solving these issues is the primary motivator behind DevOps. Often misinterpreted as a buzzword endorsing development teams taking over platform and infrastructure roles, DevOps is all about development and operational modernization. Rather than operating as siloed, asynchronous teams as has been the norm for decades, DevOps represents a fundamental, holistic, organization-wide shift not only in processes and tools, but in people and culture.

The concepts of Agile methodology and continuous delivery have become popular in software development, yet they are somewhat less mature among DBAs and database developers. Joyce Wells, editor at Database Trends and Applications (DBTA), spoke with Shay Shmeltzer, director of product management for Oracle Cloud Development Tools, to discuss how DBAs and SQL developers can take advantage of newer development approaches while also dealing with the unique challenges that exist in the world of database development.

Every now and again I come across the question: How can we lower latency and speed up data delivery? Irrespective of the target database, the desirable answer for the person responsible for implementing the data integration strategy may be to employ parallel processing. However, in many cases the decision to parallelize is the best answer only if better options have first been exhausted, and organizations don’t always explore those options.

Oracle introduced the autonomous database in the Oracle Cloud this past March of 2018. It is set up for data warehouse-type workloads and not yet for heavy transactional systems or even hybrid-type applications. As a Database Administrator (DBA), we know that most of our applications have hybrid to heavy transaction workloads, and of course a few data lakes or warehouses. Well, good news — on August 7, 2018, Oracle announced and made immediately available Oracle 18c autonomous database in the Oracle Cloud for transaction processing.