XII Encontro da comunidade SQLPort

Name: Gonçalo Chaves Alias: Chaves Job: Senior Analyst Company: Viatecla Im: evolution69@msn.com Tw: @gchaves Hobbies: reading, photo, gaming Email: gchaves@viatecla.com Communities: xamlpt, pontonetpt, sqlport

“The biggest problem in databases is the base data…”

Main challenges Why we don’t care Analysis and procedures Tools Use Cases References

Engineers knows programing but they don’t know SQL!

Rookies don’t thing in scalability!

High availability Scale and Scale Trustful transactions Performance and tuning Maintenance and archiving Partitioning Data integrity

The easy path Comfort, learning is a painful process No professional training No time! The big truck rule Scale and trust aren’t known “Microsoft’s lema”

Don’t know the engine Wrong Assumptions Re-use views, queries, with no limits Data type? What? nvarchar don’t fit in all? Unknown Transaction Isolation levels Tons of locks on a single query

Normalization

Careful to much can be inefficient

Appropriate Keys and Indexes Right Primary and FK’s

Choose for relations and integrity

Don’t over on Indexes

Take’s disk space

Drop index for bulk insertion

Some WHERE’s clauses can’t take advantage on ix

Evaluate and test you ix

Each Database is a Database

BETWEEN can be more efficient than operators

Native functions (Convert, format…)

Aggregate functions (max, min, count, …)

The NULL cancer… you must know NULL well

ISNull can be a painful

Wrong assumption on fields

Null datatype vs “Null”

Non safe transaction

Logic looseness

My debug:

Profiler… yeah it’s heavy but it’s useful!

TA – tuning advisor

Activity monitor

Look for index, keys, fragments,

Daily, every sql dev is also an sql admin!

RedGate suite

QueryExpress (light, keep simple)

TableDiff.exe

DMVStats (dataware house)

SQL Server Cache manager

DBA? Where?

SQL Internals Viewer

SQLQueryStress (in dev or stage scenarios)

SQLIO Disk Benchmark tool (on server)

SQL Security

Roles may be insufficient

Prevent SQL injection

Prevent non logic queries that can burn your data

Remember, it’s more easier broke sql security by your app than anything else.

The devil ….

SELECT *

Dam accelerators …. ADO.NET

SQLDATASOURCE

LINQ to SQL

Entity Framework …

Abuses on Group by ; Having; Inner join

Sub queries with sub queries with …

#temp_table for everything…

DML cmd’s

Constraints for everything…

Good sense

Know your data

Maintenance

Job your data Integrity vs Performance

The balance is the key

0

1

2

3

4

5

Jan Fev Mar April May June

Frag

Perf

Disk

Database – xpto 1500 tables

2700 stored procedures

~1.5 M transaction per day Delete in cascade … Broke process

Restart server

Normalize has needed Test your database Schedule jobs Create Index’s where needed Use right tools

full text search, TA, SSIS

Avoid triggers Partitioning Archive data Data type right usage Think in your transaction mode Use safe locks Test, application stress and faulty

Document you DB Keep scripts in safe Update your scripts Use facts not assumptions Cross your test with others Right lock safe usage Define db architecture

A good DB start’s on your apps Cache is more than welcome “The 4 connections challenge..” Multiple Environments keep DB’s updated Keep your analysis update

Developers exists in C# not in SQL – Deal with it!

Train your team – code review; sessions; books

Use the right tools on right scenarios

Integrity vs Performance

Keep in mind security concerns

Make Maintenance plans – from the beginning

Usual blog’s / Communities SQL 2008 internals Write Smart Sql SQL For Smarties Sql forums … sqlport

Thank you all Do right SQL before the pain! Follow me at:

http://pontonetpt.org/blogs/chaves http://xamlpt.com/blogs/chaves

gchaves@viatecla.com www.viatecla.com