Prevent Row Deletions/Updates on SQL Server

If you reach a requirements to prevent some table for deletions or/and updates you may wonder how to reach that. The simple answer is to use INSTEAD OF  triggers. INSTEAD OF triggers override the standard action of triggering statement: INSERT, UPDATE or DELETE. On that way, INSTEAD OF trigger can ignore parts of the batch, not process part of the batch or taking an alternative action. The major difference to the AFTER triggers is that INSTEAD OF triggers can be defined on a views as well as on a tables.

So, a solution of the problem, preventing a row deletions on the table can be the following INSTEAD OF trigger:

CREATE TRIGGER trgPreventRowDeletion ON Test_table INSTEAD OF DELETE
AS
BEGIN
REISEERROR ('Deletions are not allowed from the Test_table', 16, 1)
END

On a similar way it can be defined INSTEAD OF INSERT and INSTEAD OF UPDATE triggers.

Identifying Index Fragmentation on SQL Server

The first thing you are doing when identifying poor query performances is to take a look at execution plan and indexes usage. Even that you see, everything is fine, your index can be fragmented so that SQL Server needs to make unnecessary data reads to execute query. At the end, your query is slow.
At the moment when index is created, little or no fragmentation is present. During the time, when updates, inserts and deletes occur indexes get fragmented what is a real bottleneck in a SQL Server performances.

There are two ways how to fix fragmented indexes: reorganizing or rebuilding them. Which operation is necessary depends on the level of fragmentation. Reorganization of index is suggested if fragmentation level is less than 30%. If it is more than 30% than rebuilding index is better choice.

Identifying fragmented indexes

Starting from version 2005, SQL Server contains a number of DMVs and DMFs qhich allow us to retrieve informations about SQL Server health and performances and identifying problems. One of them, allow us to take a look at the index fragmentation level - sys.dm_db_index_physical_stats DMF. It is important to said here that it places intent shared lock (IS) on the affected tables during execution.

sys.dm_db_index_physical_stats (
{ database_id | NULL | 0 | DEFAULT }
, { object_id | NULL | 0 | DEFAULT }
, { index_id | NULL | 0 | -1 | DEFAULT }
, { partition_number | NULL | 0 | DEFAULT }
, { mode | NULL | DEFAULT }
)

The following query will get fragmentation of all indexes in the database

DECLARE @dbId int

SET @dbId = db_id('YOUR_DB_NAME')

SELECT s.[name] AS SchemaName, t.[name] AS TableName, i.[name] AS IndexName, p.[index_type_desc], p.[avg_fragmentation_in_percent]
FROM [sys].[dm_db_index_physical_stats](@dbId, NULL, NULL, NULL , 'DETAILED') p
INNER JOIN [sys].[tables] t  ON p.[object_id] = t.[object_id]
INNER JOIN [sys].[schemas] s  ON t.[schema_id] = s.[schema_id]
INNER JOIN [sys].[indexes] i  ON p.[object_id] = i.[object_id] AND p.index_id = i.index_id
WHERE t.[is_ms_shipped] = 0

To get more proper candidates for rebuilding or reorganizing indexes it is necessary to consult other fields returned back from [sys].[dm_db_index_physical_stats] like avg_page_space_used_in_percent which indicates on average how full each page in index is. The higher number is better while but it is necessary here to balance fullness against the
number of inserts into index pages in order to keep the number of page splits to the absolute minimum. This exceeds the topic of this blog and requires adjustments of index fillfactor and monitoring of page splits.

ORA-01489: result of string concatenation is too long

 

One of  our customers reported us this error during reading stored procedures from Oracle database. What have caused this error? USER_SOURCE view retrieve name, type and line by line of function/stored procedure definition. Each line in a new row. We used hierarchical queries and sys_connect_by_path function to concatenate all of those lines in one which keeps the full function/stored procedure definition.

The problem is, that SQL in Oracle is able to return just 4000 bytes in one column. So, if any string is longer than 4000 bytes in concatenation you will get this error. And there is no possibility to fix it. You must change logic, use chunks or something similar (CLOBs).

As a small notice, T-SQL variables can be used for concatenation very big strings which exceeds 4000 characters. Again, you will not be able to return it back with SQL.

As a sample, the following code produces the error:

select rpad(' ',4000)||'1' as 4001StringLength
from TestTable

but the following is fine:

declare
testVar   varchar2(32767);
begin
testVar := rpad(' ',4000)||'1'
end;

MySQL 5.4

New Features

MySQL has released a new version of database server – MySQL in version 5.4. Latest release was 5.1 with a really great features. This one brings not so much but also very important features:

• InnoDB storage engine can address more than 4 CPU’s/cores. Thjs helps that MySQL scale much better under huge application workloads.
• Till now, subqueries were well known as performance problematical. In version 5.4 subquery optimization has been improved a lot in a number of various use cases. As MySQL mentioned in the example below, execution time dropped from 12 minutes (9 000 000 reads) on MySQL 5.1 to just 1.8 seconds (153 000 reads) on MySQL 5.4

SELECT COUNT(l_orderkey) FROM lineitem
WHERE l_linenumber=1 AND
      l_orderkey IN
      (SELECT o_orderkey FROM orders
         WHERE o_totalprice > 1000 AND
               o_custkey IN
               (SELECT c_custkey FROM customer
                  WHERE c_address LIKE 'Le%'));

• MySQL 5.4 offers a new much better join algorithm which speed up execution time of multi-way joins like in the following example

SELECT COUNT(*) FROM part, lineitem
       WHERE l_partkey=p_partkey AND p_retailprice>2050
             AND l_discount>0.04;

• Improved error handling – through the implementation of standard SQL (SQL 2003) SIGNAL and RESIGNAL operations in stored procedures, functions and triggers developers are able to signal rule violations during execution.

Must mention here that Oracle and SQL Server not implement this functionality but have their own mechanisms: Oracle through RAISE and SQL Server through RAISEERROR statements.

• INFORMATION_SCHEMA got a new objects PARAMETERS. We wait a lot on this.


• In prior version of MySQL out parameter were not possible in prepared statements. That has been changed now.

This is all from programmers perspective. Have a fun.

Compare SQL Server, Oracle and MySQL database with DBTYP.NET Studio

Table 'mysql.proc' doesn't exist.

Sometimes our support team receive a helpdesk request concerning this error message shown in Schema Comparison of DBTYP.NET 2009 Studio.

The usual problem with such a customers is that almost all of them make recent upgrade of MySQL server. While some releases of MySQL introduce changes in the structure of the system tables in mysql database to add new privileges and support new features, it is necessary to update the system tables as well.

This can be achieved by running mysql_fix_privilege_tables script in MySQL prior to version 5.1.7 or mysql_upgrade in version 5.1.7 or above.

For more details check following links:

• http://dev.mysql.com/doc/refman/5.1/en/mysql-fix-privilege-tables.html
• http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html

See all database differences and dependencies with DBTYP.NET Studio

DBTyP.NET 2008 Release 3 Available

BYPsoft announced the availability of DBTyP.NET 2008 Release 3, the newest version of the cross-database comparison tool that compares SQL Server, MySQL and Oracle databases (schema and data). DBTyP.NET 2008 Release 3 is available for download from http://www.bypsoft.com.

With its rich support for schema and data cross-database comparison, DBTyP.NET takes the mystery out of databases, making their comparison practical and easy for programmers and database administrators everywhere. Over and above its powerful comparison capabilities till now, BYPsoft added to the DBTyP.NET 2008 support for schema comparisons for Oracle databases. Full cross database comparison family includes now support for SQL Server, MySQL and Oracle databases in the latest release of DBTyP.NET 2008 for a fraction of the cost of single-database solution.

Since the DBTyP.NET is under constant development, user interface has been redesigned and rich visual interface and easy-to-use features of DBTyP.NET 2008 allow developers and DBAs to identify and deploy changes quickly on all supported databases and enhance productivity and maximize results. Features like colorfull differences, different objects icons, visual column description, in place colorfull script differences, multiple views and more all save time and ensure accuracy.

In addition to all the new features listed above, in the latest release of DBTyP.NET 2008 BYPsoft includes also the following:

• SQL Server 2008 Ready
• Support for SQL Server ROWGUIDCOL
• Filtered out system objects on SQL Server databases.
• Support SQLServer user defined types.
• Support MySQL ENUM and SET data types.

We know that constant development is the key to progress, therefore we already started working on all new cool features. Stay with us.

List All Functions and Stored Procedures definitions in Oracle schema

A long time I have not published anything. BYPsoft preparing new version of DBTyP.NET with full support for a Oracle schema comparison and therefore didn't had any free time left for this blog.
A very interesting topic came to me out of this experience.
Have you ever tried to get a list of all stored procedures and functions in Oracle schema? Preaty easy,
SELECT * FROM USER_PROCEDURES;
You figured out that it is quite different comparing to SQL Server and MySQL where with the single query
SELECT * FROM INFORMATION_SCHEMA.ROUTINES;
you get a body definition as well.
To achieve this on Oracle is not so simply. First, to get user sources you should query USER_SOURCE view where each function or stored procedure line is stored in one row.
To get a full body, you have to use a powerful hierarchical query clause SYS_CONNECT_BY_PATH.
Here is a query which returns you list of all stored procedures and functions in Oracle schema together with their bodies defined in one column:

SELECT routine_name, y.TYPE, TRANSLATE(LTRIM(x.text1, '/'), '/', ' ') routine_definition
FROM (SELECT name routine_name, LEVEL lvl, sys_connect_by_path(text, '/') text1
FROM USER_SOURCE
CONNECT BY LINE - 1 = PRIOR LINE AND name = PRIOR name) x,
(SELECT name, TYPE, MAX(line) AS maxline
FROM USER_SOURCE
GROUP BY name, TYPE) y
WHERE x.routine_name = y.name AND x.lvl = y.maxline
ORDER BY TYPE, routine_name

Compare database schema and data fast and easy with DBTYP.NET Studio