Guys, Don’t surprise with this question. If you are in front of me, surely I will ask this question in an interview. I know, most of you are using ‘SELECT *’ in T-SQL code.

I already shared an article on ‘SELECT *’ to be good or bad.

SELECT all columns to be good or bad in database system

Regarding database coding standard, I am always strict and even I never allow single extra space in T-SQL Code.

Let me share my experience,

In my group, I already set guidelines like ‘do not use SELECT *’, but then also I found total 320 ‘SELECT *’ statements out of 2125 statements in our project.

The Developers are always running with their practice, but as DB Professionals we must prevent SELECT *.

When I found these bad queries, and I didn’t react immediately. I had been waiting for tight deadlines. Before a month ago I scheduled an internal demonstration.

On this occasion, I planned the penalty for those developers who wrote ‘SELECT *’ in their stored procedures.

In the morning, I added one extra overnight computed column on those tables. The computed column was (BadSelect AS (1 / 0)), that means if anyone is selecting data using ‘SELECT *’, they get error like ‘Divide by zero error encountered’ and fails the execution of a query.

Now after this alteration, developers had removed all ‘SELECT *’ and we started our demonstration late by 3 hours.

It is OK for me, but next time they will never put ‘SELECT *’ in T-SQL Code.

Use below demonstration, to test this exercise and prepare yourself for this kind of interview questions as well.

Generate a script to add computed column in all the table:
You can copy script for requiring a table and can create computed column.

SELECT 'ALTER TABLE ' + name + ' ADD BadSelect AS (1 / 0) 
GO'
FROM sys.tables

If developer execute ‘SELECT *’, they will get a bellow error:

Msg 8134, Level 16, State 1, Line 1
Divide by zero error encountered.

Generate a script to remove computed column from all the table:

SELECT 'ALTER TABLE ' + name + ' DROP COLUMN BadSelect 
GO'
FROM sys.tables

Should we allow NULL or We should apply NOT NULL?

Database Design: Should we allow NULL or We should apply NOT NULL ?

“SELECT *” is good practice or bad practice in database system?

SELECT all columns to be good or bad in database system

What is Left Anti Semi Join Operator?

The Left Anti Semi Join operator returns the result set for each row from the first (top) input when there is no matching row in the second (bottom) input. If no join predicate exists in the Argument column, each row is a matching row. Left Anti Semi Join is a logical operator.

Why you should not use a cursor? What are its alternatives?

Microsoft requests us to avoid using cursors due to Memory and RAM overhead including comparatively more DISK IO. Alternatives: WHILE LOOP / CASE / Temprary Tables / Derived Tables / Sub Queries can be used in place of Cursors.

What are Dynamic Queries in T-SQL?

Dynamic T-SQL Queries are those queries designed on the fly / at run time using Variables or using CTE or other sources. We use SP_EXECUTESQL Stored Procedure or EXECUTE function to execute such queries.

How you can load large data in SQL Server?

IMPORT and EXPORT Wizard, BULK INSERT and BCP are the possible options. We need to set the RECOVERY MODEL to BULKLOGGED before we perform such activities.

What is Mutex error in Triggers?

The only use of “mutex” that I know of is for a mechanism for re-entrant code that can’t be simultaneously executed by multiple processes to force that code to be single threaded.  It’s not a typical SQL Server term.  If it were, it would apply as much to stored procedures as triggers.  Generally, in a well designed database with well written code, this would be handled by using standard data locking and transactions.

What is the use sp_refreshview?

It updates the metadata for the specified non-schema-bound view. Persistent metadata for a view can become outdated because of changes to the underlying objects upon which the view depends.

Syntax:

EXECUTE sp_refreshview ‘view_name’;

Can you create a Primary key without clustered index?

Yes, you can create a Primary Key with a Non Clustered Index. But by default creation of PK automatically creates a clustered index upon the table.

What are the virtual tables in Triggers?

Inserted & Deleted are virtual tables in Triggers.

How will you know what indexes a particular table is using?

By checking the graphical Execution Plan.

By using sys.dm_db_index_usage_stats DMV.

How many types of internal joins are there in SQL Server?

• Nested loop join
• Merge join
• Hash join

What are Join Operators?

A join operator is a type of an algorithm which the SQL Server Optimizer chooses in order to implement logical joins between two sets of data.

The SQL Server Optimizer may choose a different algorithm for different scenarios based on the requested query, available indexes, statistics and number of estimated rows in each data set.

It’s possible to find the operator which was used by looking at the execution plan that SQL Server has prepared for your query.

What are the Nested Loops Joins?

The nested loops join, also called nested iteration, uses one join input as the outer input table (shown as the top input in the graphical execution plan) and one as the inner (bottom) input table. The outer loop consumes the outer input table row by row. The inner loop, executed for each outer row, searches for matching rows in the inner input table.

In the simplest case, the search scans an entire table or index; this is called a naive nested loops join. If the search exploits an index, it is called an index nested loops join. If the index is built as part of the query plan (and destroyed upon completion of the query), it is called a temporary index nested loops join. All these variants are considered by the query optimizer.

What are the Merge Loops Joins?

The merge join requires both inputs to be sorted on the merge columns, which are defined by the equality (ON) clauses of the join predicate. The query optimizer typically scans an index, if one exists on the proper set of columns, or it places a sort operator below the merge join. In rare cases, there may be multiple equality clauses, but the merge columns are taken from only some of the available equality clauses.

Because each input is sorted, the Merge Join operator gets a row from each input and compares them. For example, for inner join operations, the rows are returned if they are equal. If they are not equal, the lower-value row is discarded and another row is obtained from that input. This process repeats until all rows have been processed.

What are the Hash Joins?

Hash joins are used for many types of set-matching operations: inner join; left, right, and full outer join; left and right semi-join; intersection; union; and difference. Moreover, a variant of the hash join can do duplicate removal and grouping, such as SUM(salary) GROUP BY department. These modifications use only one input for both the build and probe roles.

What is Logical Join and Physical Join?

Logical Joins: These joins are simple joins that we apply in our SQL queries, like INNER JOIN, RIGHT/LEFT OUTER JOIN, CROSS JOIN, OUTER APPLY, etc.

Physical Joins: These are the joins that users don’t use/write in their SQL queries. Instead these are implemented inside SQL Server engine as operators or algorithms to implement the Logical Joins. Their types are Nested Loop, Merge and Hash.

What is an In-Memory Hash Join?

The hash join first scans or computes the entire build input and then builds a hash table in memory. Each row is inserted into a hash bucket depending on the hash value computed for the hash key. If the entire build input is smaller than the available memory, all rows can be inserted into the hash table.

This build phase is followed by the probe phase. The entire probe input is scanned or computed one row at a time, and for each probe row, the hash key’s value is computed, the corresponding hash bucket is scanned, and the matches are produced.

What is a Grace Hash Join?

If the build input does not fit in memory, a hash join proceeds in several steps. This is known as a grace hash join. Each step has a build phase and probe phase. Initially, the entire build and probe inputs are consumed and partitioned (using a hash function on the hash keys) into multiple files.

Using the hash function on the hash keys guarantees that any two joining records must be in the same pair of files. Therefore, the task of joining two large inputs has been reduced to multiple, but smaller, instances of the same tasks. The hash join is then applied to each pair of partitioned files.

What is a Recursive Hash Join?

If the build input is so large that inputs for a standard external merge would require multiple merge levels, multiple partitioning steps and multiple partitioning levels are required. If only some of the partitions are large, additional partitioning steps are used for only those specific partitions. In order to make all partitioning steps as fast as possible, large, asynchronous I/O operations are used so that a single thread can keep multiple disk drives busy.

If the optimizer anticipates wrongly which of the two inputs is smaller and, therefore, should have been the build input, the build and probe roles are reversed dynamically. The hash join makes sure that it uses the smaller overflow file as build input. This technique is called role reversal. Role reversal occurs inside the hash join after at least one spill to the disk.

What is COMPUTE BY statement?

COMPUTE BY statement has both detail and summary rows within the SELECT statement. It calculates the summary values for subgroups, or a summary value for the entire result set.

In this post, I am sharing the major difference between SET and SELECT, which we are using for assigning a value to the Variable of SQL Server.

What I have found is, the people are always confused to use SET or SELECT for assigning a value to the Variable and which one is faster ?

SET is the ANSI standard, and SELECT is not the ANSI standard.

Using SET, we can only assign a scalar value, and if the query is returning multiple values, SET will raise an error.
In contrast, SELECT never raises an error if the query is returning multiple values.

Using SET, we can assign one variable at a time, using SELECT we can assign multiple variables at a time.

There are not major differences in speed and performance, but SELECT is slightly faster than SET because it can perform multiple assignments at a time.

As per the ANSI standard, If there is no value returned, SET will assign NULL and SELECT will not assign any value and variable will not be changed from its previous value.

For this Difference, I prepared a small demonstration here.

Create table with Sample Data:

CREATE TABLE [dbo].[tbl_Employee]
(
	EmpID INTEGER IDENTITY(1,1)
	,EmpName VARCHAR(255)
	,Gender CHAR(1)
	,DOB DATETIME
	,CONSTRAINT pk_tbl_Employee_EmpID PRIMARY KEY(EmpID)
)
GO

INSERT INTO [dbo].[tbl_Employee]
(EmpName,Gender,DOB)
VALUES
('Anvesh','M','19880126')
,('Roy','M','19930214')
,('Jenny','F','19920320')
,('Martin','M','19850616')
GO

Assigning variable using SET:

DECLARE @EmpName VARCHAR(255)
SET @EmpName = 'Anu'
SET @EmpName = (SELECT EmpName FROM [dbo].[tbl_Employee] WHERE DOB ='19880127')
SELECT @EmpName /* @EmpName is NULL */
GO

Assigning variable using SELECT:

DECLARE @EmpName VARCHAR(255)
SET @EmpName = 'Anu'
SELECT @EmpName = EmpName FROM [dbo].[tbl_Employee] WHERE DOB ='19880127'
SELECT @EmpName /* @EmpName still having a value 'Anu' */

In this post, I am going to start a small series of articles which divided into four different parts.

In this set of articles, I will provide basic theory and practical to perform cross-platform or cross-server queries in MySQL. We can also say remote queries.

Some of the Database Professional already aware about Linked server object of Microsoft SQL Server, which is used for cross-server queries.
Many times, we need to SELECT data from the different database server and even, we require to fetch data from various RDBMS products as well.

MySQL also provides the FEDERATED Storage Engine to access data from a remote MySQL Database Server.

The FEDERATED Storage Engine is available beginning with MySQL 5.0.3.

We don’t require to write any database level trigger to update real-time data into the local FEDERATED table because it is fetching data remotely and even does not need to store that data physically on the hard disk.

We can query to the local FEDERATED table like any other normal table, but it is working as a virtual table only.

The FEDERATED storage engine is not enabled by default in the running server.
You can visit the next article to configure and enable FEDERATED Engine.

In this post, I am going to write about one of the most common mistakes of Database Developers.

“SELECT * ” (SELECT all columns) to be good or bad in a Database System.

I will discuss the pros and cons of “SELECT * ” and what should be our best practice with SELECT all columns.

Don’t go with ” SELECT * “:

• When you are using ” SELECT * “, you are selecting more columns from the database, and your application might not use some of this column. This will create extra cost and load on the database system, and unnecessary data travels across the network.
  

  ---

• When you are using JOIN between two or more tables, and in that query, you use “SELECT * “, guess about two columns with the same name. It will return more columns than you needed and will create a binding problem.
  

  ---

• If you are using “SELECT * “, you may get all columns in arbitrary sequence, and if specified the column name, it will return in the specified order, and you can also refer to this column by numerical index.
  If such a code exists in an application which requires all columns in a predefined order, you have to specify all the columns name in the correct order.

  ---

• When you are using “SELECT *”, you will face performance issue because this is not advisable to apply an index on all the columns of the table.
  

  ---

• When you are using “SELECT *”, you require to create documentation for those columns which are returning and using by an application otherwise, this will create confusion.
  

  ---

• When you are using “SELECT * ” and in the future, someone adds one new column with TEXT data type, you can imagine performance and other errors.
  

  ---

• If you need to select all columns, also I would suggest providing a full list of columns because putting “SELECT *” needs fetching the name of the columns from stored metadata or system information which will impact the query performance.
  

  ---

• Now Imagine that you are using “SELECT *” in all your stored procedure and now you require to find one column name from the text of the stored procedure which is not possible with “SELECT *”.

Why you go with “SELECT *” ?

• The Lazy developers can only go with “SELECT *”.
  

  ---

• If you have special requirements and create a dynamic environment when add or delete column automatically handle by application code. In this particular case, you don’t require to change application and database code, and this will automatically be done in a production environment. In this case, you can use “SELECT *”.
  

  ---

• I didn’t find any other reason to use “SELECT *”.

In this post, I am sharing a script which we can use for changing ownership of all objects in PostgreSQL.

Why ownership of object needs to change?

I have created one application user for our production PostgreSQL database.

But system admin and deployment manager made one mistake and executed objects with some another database user.

After deployment, we came to know that objects were not deployed under proper ownership.

Now we have 2500 tables, 450 views and 230 stored functions are required to change their ownership.

Now, I need to solve this by using only one script because of manual changing ownership of this many objects will take too much time.

Below is my demonstration:

Let’s First, create one function with $parameter value so that you can use this function as a template.

CREATE OR REPLACE FUNCTION ChangeObjectsOwnerShip(text) 
returns text language plpgsql volatile
  AS $f$
    BEGIN
      EXECUTE $1;
      RETURN $1;
    END;
$f$;

Now generate two select statements to get the alter script.

Below select statement is for Tables, Sequences and Views.

SELECT ChangeObjectsOwnerShip
(
 'ALTER TABLE ' || quote_ident(s.nspname) || '.' ||quote_ident(s.relname) || ' owner TO app_user'
)
FROM 
(
 SELECT 
  nspname
  ,relname
 FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid) 
 WHERE nspname NOT LIKE E'pg\\_%' 
  AND nspname <> 'information_schema' 
  AND relkind IN ('r','S','v') ORDER BY relkind = 'S'
)s;

Below select statement is for all functions.

SELECT ChangeObjectsOwnerShip
(
 'ALTER FUNCTION ' || quote_ident(s.nspname) || '.' ||quote_ident(s.function_name) || '('||s.parms||') owner TO app_user'
)
FROM 
(
 SELECT 
  nspname
  ,proname AS function_name
  , pg_catalog.oidvectortypes(proargtypes) AS parms
 FROM pg_catalog.pg_proc AS c
 JOIN pg_namespace n
  ON (c.pronamespace = n.oid)
 WHERE nspname != 'information_schema'
  AND nspname NOT LIKE E'pg\\_%'
 ORDER BY proname
)s;

In above code, preparing one alter statement to change ownership for all objects from assign user to mentioned ” app_user “. You can change ” app_user ” by your require user name.

After executing above select statements, you can find all alter scripts in a result.

Copy this result and execute above alter scripts using super user.

All ownership will be changed after executing this alter the script.