• Query optimization: The most most important fact for DB optimization is to tune in your queries for faster data manipulation activities. Frequently check slow query log and tune the heavy resource intensive queries.
• Master-Master Replication:
• In Memory Usage:
• Thread Concurrency:
• RAID: Move your servers disk on RAID environment
• Key Parameters:  Tune our key parameters for faster CRUD operations.

Hope implementing above mentioned techniques you will be able to optimize your MySQL.

Many times in your organization an issue is raised that SQL server database is very much slow and its performance is not up to the mark. First thing that comes in mind is are indexes correctly applied to table that are being used? And most of the time indexes are applied, than what is the issue.

Most users think that only indexes are the reason for bad performance of a SQL server database, this is not true, there are many other reasons for slow response from your DB.

Following are some of the areas each of which are to be checked separately for resolution of performance issues in a SQL Server database:

Joining Techniques

Optimization of Queries used

Maintaining up to date Statistics

Logical Query Processing

TempDB tuning

Hardware Issues (slow hard disks, CPU, Memory etc)

Index Tuning

If all above areas are checked and planned properly, then probability of slow response from a SQL server database are very much minimized.

The major features of the new products are as following:

• Enhanced Mission-Critical Platform: an enhanced highly available and scalable platform.
• Developer and IT Productivity: new innovative productivity tools and features.
• Pervasive Insight: expanding the reach of BI to business users and end-to-end data integration and management.

Now here a little script that will retrieve the size of database monthly. For execution of this script you will need to have select privilege on sys.v_$datafile view. Following query will retrieve results based on months, however you can easily tweak this query for creation_time column to get any type of extracts.

Script

select to_char(creation_time, 'YYYY Month') "Month",
    sum(bytes)/1024/1024 "Growth in MB"
    from sys.v_$datafile
    where creation_time > SYSDATE-365
    group by to_char(creation_time, 'YYYY Month');

Result

Month          Growth in MB
-------------- ------------
2010 December             2
2010 November            100

Description

It means that your session is trying to update an object that locked by another session. More specifically, your session has asked for a lock on the same object, but has specified the ‘nowait’ clause. The nowait clause, upon finding something locked, returns an error, rather than waiting for the lock to be released.

Solution

1. Run your script some other time, when database becomes idle or the object you want to update is lock free.
2. Kill the session that has the lock on the object.

For killing locked sessions following is the link to post that explain it in detail:

http://technoblogy.net/killing-locked-sessions-in-oracle/

For example:

SELECT A.USER1, A.USER2, B.ROLENAME

FROM USERS A, ROLES B

WHERE A.ROLEID = B.ROLEID

A.ROLEID and B.ROLEID both have different collations and it upon executing above query it will generate an error: “cannot resolve collation conflict.

To resolve this error add COLLATE DATABASE_DEFAULT on both side of equal operator:

SELECT A.USER1, A.USER2, B.ROLENAME

FROM USERS A, ROLES B

WHERE A.ROLEID COLLATE DATABASE_DEFAULT = B.ROLEID COLLATE DATABASE_DEFAULT

Resolved.

After searching on internet i came across a DMV(Dynamic Management View) provided in SQL Server. This view has almost every detail of a single process executing in SQL Server.

DMV – sys.dm_exec_requests

Following script returned my desired result of percentage completed of my backup job:

SELECT Session_Id, Reads, Writes, Cpu_Time, Logical_Reads, Total_Elapsed_Time,

Blocking_Session_Id, Percent_Complete, Command,

(select text from sys.dm_exec_sql_text(sql_handle)) as Text FROM

sys.dm_exec_requests(nolock) WHERE session_id = 90

Hope this helps.

While searching across internet, i came across a script that will list all the tables in my database and also show how many indexes are created/applied on those table wither clustered or non clustered.

Here’s the script:

with cte as
(
select
table_name = o.name,  �
o.[object_id],
i.index_id,
i.type,
i.type_desc
from
sys.indexes i
inner join
sys.objects o on i.[object_id] = o.[object_id]
where
o.type in (‘U’)
and
o.is_ms_shipped = 0 and i.is_disabled = 0  and i.is_hypothetical = 0
and
i.type <= 2
), cte2 as
(
select
*
from
cte c
pivot
(count(type) for type_desc in ([HEAP], [CLUSTERED], [NONCLUSTERED])) pv
)
select
c2.table_name,
[rows] = max(p.rows),
is_heap = sum([HEAP]),
is_clustered = sum([CLUSTERED]),
num_of_nonclustered = sum([NONCLUSTERED])
from
cte2 c2
inner join
sys.partitions p on c2.[object_id] = p.[object_id] and c2.index_id = p.index_id
group by
table_name

More details can be found here

You need to know every single path from where this procedure is initiating before you can actually remove it from production. Following are some ways to determine the usage of a procedure in SQL Server.

1. Set up a trace and filter through SQL Server profiler service on procedure name and ID.
2. Another way is to regularly check procedure plan cache to see if there is a cached plan for the procedure.
3. Alternatively you can use a 3rd party audit software to retrieve procedure executions. (Most of these soft wares use tracing at the back end)\