Tag: Oracle

PL/Sequre – PL/SQL Code Protection

PL/Sequre is a PL/SQL based application designed to combat software theft of your own PL/SQL code. PL/Sequre essentially performs a PL/SQL obfuscation process on your source code. It does this by converting all user defined identifiers into meaningless hashed strings to make the code almost impossible to understand, and therefore enabling code protection. PL/Sequre also has the added advantage of allowing license checking code to be hidden in your PL/SQL code along with anti-tampering checksum code ensuring no unauthorised use.

Software Theft

The very nature of PL/SQL means that by default the source code is there to be seen by anyone with access to the owning schema in the database. For in-house bespoke solutions, the lack of code protection may not pose so much of a threat, but for PL/SQL solutions developed for the commercial market, where there may be valuable intellectual property to protect, the PL/SQL code protection against software theft is critical.


Oracles’s own wrap.exe utility has been continuously cracked over several major releases, with a number of unwrap solutions openly on offer for download, risking valuable intellectual property to software theft. Oracle does not seem to be improving this utility, with the 9i version considered the most secure, so provides very little code protection.


PL/Sequre is a PL/SQL obfuscation utility developed in PL/SQL using the Oracle 12g R2 PL/Scope functionality. It acts as a another layer of protection against software theft, and can be used independently or to compliment the existing wrap.exe utility.

How it Works

It works by hashing user defined identifiers in the raw PL/SQL source code which includes variables, constants, procedure and function names with their arguments, internal types and their column names, but will exclude all externally referenced object names. The resulting hashed names become totalling meaningless making it virtually impossible to understand the code. It can also handle dynamic SQL and obfuscate code within quoted strings, as long as the recommended approach has been adopted.

Summary of Features

These are the main features to be found in PL/Sequre:

  • A simple PL/SQL package, run from SQLPlus or any other SQL IDE such as TOAD or SQLDeveloper
  • Obfuscation of stored procedures/functions, packages, object types, and triggers
  • Requires virtually no pre-configuration to start obfuscating .
  • Option to leave package specifications un-obfuscated so public API still useable (will leave all public functions/procedures and their arguments referenced in the package body un-obfuscated).
  • Option to generate a non-obfuscated wrapper package over a package that has been totally obfuscated (both specification and body). So no identifiers are left un-obfuscated in the body.
  • Able to encrypt dynamic SQL with quoted text if using recommended techniques
  • Can embed anti-tampering functionality to prevent any unauthorised changes to crack licensing code.
  • Outputs to one of several formats such as directly to file system, to a CLOB, or directly compiled into to the database.
  • Obfuscated identifier names persisted to a table for consistent use across a suite of PL/SQL objects or re-obfuscation of the same code.

Denormalised Design: Prime Numbers and SQL

Many may think that prime numbers are for the mathematicians to play with, and bit of an obscure combination to use with SQL. However, they can be very useful for implementing a compressed data solution providing some additional set theory operations difficult to achieve in SQL.

ETL/Express – Bulk Data Loading Tool

If you are an organisation challenged with reducing the costs and improving the performance of your Oracle based ETL solutions, and meeting the demands of DevOps and Cloud Computing, then we may be able to help with our simple, low cost, and highly effective and efficient PL/SQL based ETL tool ETLExpress.

The Challenges

Data warehouses processing very large data volumes with complex multiple concurrent feeds can be immensely difficult to successfully deliver.  As a result, there can be big challenges associated with minimising ETL batch times, eradicating concurrent data loading issues to improve throughput, meeting minimum expected developer skill levels, and justifying the cost of expensive enterprise ETL tools. Additionally, keeping on top of all of this whilst juggling with the demands of meeting DevOps and Cloud Computing requirements only exasperates the challenges.

The Questions

Please take a look at these points to see if ETLEx/press can help you:

  • Are you using Oracle 11g or higher to perform your ETL tasks being into, out of, and within the databases?
  • Do you pay for expensive licences for your enterprise ETL technology?
  • Do you rely on costly specialist resources to administer, develop, and support your ETL solutions?
  • Are your ETL solutions challenged with continuing performance and scalability issues?
  • Find that you have limited scope to improve performance without resorting to bespoke PL/SQL ETL solutions
  • Do your bespoke PL/SQL based ETL solutions lack adequate frameworks, and beyond your in-house skills set to stabilise or improve?
  • Are you under pressure to reduce your IT skills and training costs, with possible outsourcing and/or off-shoring?
  • Are you looking to improve your IT development throughput and time-to-market for your data warehousing solutions?

The Answer

So, answering yes to most of the above will more than likely mean our feature-packed comprehensive ETL application ETL/Express  can help you.

Database Design: Block Size Design

A database designer has a number of factors to consider when determining a tablespace strategy for a database. A big influence on this is the block size of a tablespace, and if not the default size, how they will work with the various caches.

Data Generation: Techniques in SQL

Software applications need to be tested and this may mean being dependent on a lot more data than can be entered through natural means. The quality and authenticity of generated data relies on the sophistication and effort put into the routines. This article describes some techniques to ease the coding.

Database Design: Missing or Bad Statistics

A common cause of poor SQL performance in an application is missing/stale CBO statistics on a table. The typical aim is to have statistics gathered on all tables belonging to an application; however there are situations where statistics are not possible or are inappropriate. This article covers the scenarios where this occurs and proposes methods to ensure that they are applied effectively.

Database Design: Block Contention

A common bottleneck on busy OLTP applications is contention on the buffer cache. If too many sessions attempt to read the same blocks from the buffer cache, then they can queue up waiting for low level latches to be released before they can read the blocks from the cache.