Full with practical examples and real world scenarios.

If you signup to the Email Updates you will receive the scripts used in the webcast.

As described in Oracle Metalink Note 854428.1 switch back to CPU “…would require significant effort, and so is not advised”.

Please comment.

Some advice to increase performance:

- Rebuild indexes (DBCC DBREINDEX)

- Update statistics (SP_UPDATESTATS)

- Check the compatibility level of the database in question.

If the compatibility level is set to 80 (SQL 2000)  change it to 90 (SQL 2005).

The compatibility level is not really related to performance but needed for use new features released with SQL 2005.

Error occured during weekend and a high amount of trace- and dump-files are generated and fill up the file system.

Investigation at Oracle Support show me that the Oracle Bug 5705795 (Doc ID 4167271) caused the problem.

I download Patch 5705795 for our linux system.

 (You need Patch 5731535 if using windows).

Stopped agent, opmn and iasconsole, shutdown the repository database and applied the patch.

After restart all oracle processes and the repository database the error no longer occured in the alert log.

But this time i found another error in the log (ORA-07445 [lstclo()+45] [SIGSEGV] [Address not mapped to object].

In my case the error occured because i don’t shutdown ALL databases which shared the same ORACLE_HOME.

The second database was open and caused the problem.

After bouncing and restart this database the error was cleared.

Recover database when transaction log deleted

Found solutions for some problems at MSDN.

Because the whole thread is confusing i collect the solutions at this site to get a clear overview.

Note: As always try at your own risk. Make a backup of your files before try the solutions.

Issue 1 – Difference of two datetime columns caused overflow at runtime.

Open C:\Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard\setup.sql.

Search for following code:

sum(convert(bigint, datediff(ms, login_time, getdate()))) – sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,

and replace this line with the code below.

sum(convert(bigint, CAST ( DATEDIFF ( minute, login_time, getdate()) AS BIGINT)*60000 + DATEDIFF ( millisecond, DATEADD ( minute, DATEDIFF ( minute, login_time, getdate() ), login_time ),getdate() ))) – sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,

Issue 2 – Blue Zone Problem (Server is running for 24 or more days).

Open C:\Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard\recent_cpu.rdl.

Go to line number 3271 and delete all lines till line number 3306.

Replace the delete lines with following code:

from (select s.session_id,
r.request_id,
s.login_time,
– s.host_name,
s.program_name,
s.login_name,
s.status as session_status,
s.last_request_start_time,
s.last_request_end_time,
s.cpu_time as session_cpu_time,
r.cpu_time as request_cpu_time,
– s.logical_reads as session_logical_reads,
– r.logical_reads as request_logical_reads,
r.start_time as request_start_time,
r.status as request_status,
r.command,
master.dbo.fn_varbintohexstr(r.sql_handle) as sql_handle,
master.dbo.fn_varbintohexstr(r.plan_handle) as plan_handle,
r.statement_start_offset,
r.statement_end_offset,
case
– Steve: Fixes begin here:
when convert(bigint, CAST ( DATEDIFF ( minute, start_time, getdate()) AS BIGINT)*60000 + DATEDIFF ( millisecond,
DATEADD ( minute,DATEDIFF ( minute, start_time, getdate() ), Start_time ),getdate() ))
> 0
then convert(float, r.cpu_time) / convert(bigint, CAST ( DATEDIFF ( minute, start_time, getdate()) AS BIGINT)*60000
+ DATEDIFF ( millisecond, DATEADD ( minute, DATEDIFF ( minute, start_time, getdate() ), Start_time ),getdate() )) else convert(float, 1.0) end
as avg_request_cpu_per_ms,
isnull (datediff(ms, case when r.start_time < @WithActivitySince then @WithActivitySince else r.start_time end, getdate()), 0)
as request_ms_in_window,
case when s.login_time > getdate() then convert(float, s.cpu_time) / (datediff(dd, s.login_time, getdate()) * cast(86400000 as bigint) + datediff(ms, dateadd(dd, datediff(dd, s.login_time, getdate()), s.login_time), getdate())) else convert(float, 1.0)
end as avg_session_cpu_per_ms,
convert(bigint,isnull(datediff(s, case when s.login_time < @WithActivitySince then @WithActivitySince else s.login_time end, case when r.request_id is null then s.last_request_end_time else getdate() end), 0)  )* 1000
as session_ms_in_window
from sys.dm_exec_sessions s
left join sys.dm_exec_requests as r on s.session_id = r.session_id  and s.session_id = 1
– Steve: Fixes end here
where (s.last_request_end_time > @WithActivitySince or r.request_id is not null)) as d
where (avg_request_cpu_per_ms * request_ms_in_window) + (avg_session_cpu_per_ms * session_ms_in_window) &gt; 1000.0</CommandText>
<QueryParameters>
<QueryParameter Name=”@WithActivitySince”>
<Value>=Parameters!WithActivitySince.Value</Value>
</QueryParameter>
</QueryParameters>
<DataSourceName>DataSource1</DataSourceName>
</Query>

Issue 3 – Arithmetic overflow error converting expression to data type datetime.

This problem appear mostly when clicking the blue cpu zone.

Open C:\Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard\recent_cpu.rdl.

Search for WithActivitySince and replace the parameter from String to DateTime.

To fix the problem:

Find the SQL-Logins which orphaned: Exec sp_change_users_login ‘Report’

Run following statement to resolve the problem: Exec sp_change_users_login ‘UpdateOne’, ‘Name’, ‘Name’

Note: This will only work for SQL-Logins.

There is a parameter “Auto_Fix“ available. I don’t use it due to security reasons.

The first article cover maintenance of the TempDB.

The second describe the use of database trigger to audit DDL operations.

In this case use the KB 253817.

So, what will happen when you create a new database on your production server because high level management need this a.s.a.p ?

You use the full recovery model to include this database in your backup strategy. Of course, the full backup will run as always later the day.

The requested department started to work with the new database. Hours later somebody reported a problem with the new database.

During investigation you find out that most of the data from the last hours are deleted and no longer available.

But, you are running the database in full recovery mode. You started with the recovery from the transaction log.

Normally this is not a big deal. This time it will not work.

Why ?

Although the database is using the full recovery model a full backup was never done.
Therefore the transaction log was reused by the SQL Server after reaching the end of the log file.

This truncation of the log file will also occur when you truncate the transaction log after the last full backup.

Above scenario may not be the best example but it show you the importance to do a full backup.