Download C#TopTenTips

loooooooooooooong
Introduction!
There are effectively 2 people I am talking to with this talk. Non-DB Developers and DB-Developers.
DB Dev
VS.
Other Dev
C# developers are not the same as a Junior DB developers.
C# developers understand complex coding patterns and methodologies and are accomplished in their fields.
How is it then that sometimes we cannot create a platform for them to dev in our space?
What causes
the most live
problems?
Speed  Either querying a table that is too big/not using indexes.
Data value – Dirty reads/bad transaction handling – non-repeatable reads.
OR we are valuing data too highly and locking a valuable resource.
The biggest
difference:
data
once it is generally understood that there are more things to realise than just accuracy (and that accuracy is no longer binary) then you are making headway.
horrible
question…
If you design your environments with multiple professional users in mind then there will be safe areas for people to just code without fear.
solution?
For every database you have you should be able to build a profile of what is and is not important – which tables are big – which tables are contentious – Lets build a list.
comments
(inline or otherwise):
Where does
description of
behaviour exist?
Major difference to (C#)compiled code is that DBA’s will be able to and will try to troubleshoot – good documentation will allow them to do this quicker.
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
Database environment – Reporting:
1. Comments: Add comments to your changelog.
Query guidelines:
Join/where clause on
columns with indexes only.
Return less than 10000 rows.
(x) tables can be dirty reads.
Your data could be super transient and you require a tab lock when querying?
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
Insert/update
heavy
VS.
readheavy or read
environments.
Here you can define different behaviours: For read heavy environments the rule could be  Add indexes for days.
For insert heavy environments the rule could be  not allowed indexes but make your keys properly sequential(ever increasing)
if you have both it may be time to chat to your architect about separating concerns 
only
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
3. [Insert Heavy] environment:
1. Do not create indexes!
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
3. [Query Heavy] environment:
1. Create any indexes you need(Join and where)
2. Update indexes (<0.5gig)
Dependencies
funnies
environment
For each DB you can point out the pot holes or hidden items, Database triggers, table triggers, Replication to or from.
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
3. [Insert Heavy] environment:
i. Do not create indexes!
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
3. [Query Heavy] environment:
i. Create any indexes you need(Join and where)
ii. Update indexes (<0.5gig)
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
Linked Servers
(Y/N)
Other options?
Most Application developers will just query twice but make a rule about best practices.
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
3. [Insert Heavy] environment:
i. Do not create indexes!
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
3. [Query Heavy] environment:
i. Create any indexes you need(Join and where)
ii. Update indexes (<0.5gig)
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
5. Linked Servers – Use any that are already there.
Temp DB
When/how should I
use temp objects?
More or less…
Depending on the environment you are in, people who are not in the know will either horribly overuse TempDB  Dumping tables there willy-nilly because they have been told that it is quicker.
The other option is guys never use it because once they used a table variable on a critical system and it spilled to disk and now they are scared!!!
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
3. [Insert Heavy] environment:
i. Do not create indexes!
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
6. TempDB:
i. Not setup for ‘Active’ use (use sparingly)
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
3. [Query Heavy] environment:
i. Create any indexes you need(Join and where)
ii. Update indexes (<0.5gig)
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
5. Linked Servers – Use any that are already there.
6. TempDB:
i. Actively use temp DB for any transform. It is huge and
on super fast storage
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS
ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_N
SET NUMERIC_ROUNDABORT
SET NOCOUNT ON
Just give everyone the same starting point. If you deviate from this it will be on your own head…
Database environment – Audit112:
1. Comments: Add comments in body of all objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000 for internal.
iii. Dirty reads allowed  *_Static and *_log.
3. [Insert Heavy] environment:
i. Do not create indexes!
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
6. TempDB:
i. Not setup for ‘Active’ use (use sparingly)
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
Database environment – Reporting:
1. Comments: Add comments to your changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data at rest.
3. [Query Heavy] environment:
i. Create any indexes you need(Join and where)
ii. Update indexes (<0.5gig)
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
5. Linked Servers – Use any that are already there.
6. TempDB:
i. Actively use temp DB for any transform. It is huge and
on super fast storage
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
iv. SET ARITHABORT ON
sizes:
Variable
tableVariable
temptable
when to add index?
something like: Variables use at will, table variables up till 10 - 100. temp tables 100 – 1000, table variables with index 1000 - 1 GB.
Database environment – Audit112:
…
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
6. TempDB:
i. Not setup for ‘Active’ use (use sparingly)
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
8. Suggested Size:
• @Table = 10 to 1000 (ensure no spill)
• No temp tables
Database environment – Reporting:
…
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
5. Linked Servers – Use any that are already there.
6. TempDB:
i. Actively use temp DB for any transform. It is huge and
on super fast storage
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
iv. SET ARITHABORT ON
8. Suggested Size:
• No table variables
• Temp tables 10 – 100000
• Temp tables(with indexes) > 100000
error handling
2 options only...
Most times not handling SQL errors is the easiest and most accurate way of failing. Alternately a try catch block - proc with rethrow logic.
Database environment – Audit112:
…
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
6. TempDB:
i. Not setup for ‘Active’ use (use sparingly)
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
8. Suggested Size:
• @Table = 10 to 1000 (ensure no spill)
• No temp tables
9. Error handling:
• Just don’t – let the error bubble up organically.
Database environment – Reporting:
…
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries will be killed]
5. Linked Servers – Use any that are already there.
6. TempDB:
i. Actively use temp DB for any transform. It is huge and
on super fast storage
7. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
iv. SET ARITHABORT ON
8. Suggested Size:
• No table variables
• Temp tables 10 – 100000
• Temp tables(with indexes) > 100000
9. Error Handling:
• Any Updates or inserts use both Try Catch and
sp_raiseLastError.
Broker,
homegrownframework?
Acceptable execution times?
Service
Try and give healthy guidelines for building anything in an established framework.
Database environment – Audit112:
…
9. Error handling:
• Just don’t – let the error bubble up organically.
10. General:
• No unnecessary load on system from 28th to 31st of
Month, Month End work takes priority!
• Add to table tb_process2Kill if your process is not
critical.
Database environment – Reporting:
…
9. Error Handling:
• Any Updates or inserts use both Try Catch and
sp_raiseLastError.
10. SSB Framework(ABC) in effect.
• All Procs must execute in <2 seconds
• SSB Procs are sp_procs_ABC_*
Concurrency
Controlling
If Data accuracy is in question. There is no shame in making no-go areas. ”This queue based system is off limits for non DB Devs…”
Database environment – Audit112:
1. Comments: Add comments in body of all
objects.
2. Query Guidelines:
i. Join and where only on Indexes
ii. Only return 10000 to client and 100000
for internal.
iii. Dirty reads allowed  *_Static and
*_log.
3. [Insert Heavy] environment:
i. Do not create indexes!
4. Funnies:
i. Replication
ii. SSB
iii. There are DB Triggers for DDL
5. Linked Servers – Do NOT use ever.
6. TempDB:
i. Not setup for ‘Active’ use (use sparingly)
1. Def. env. variables:
i. SET QUOTED_IDENTIFIER ON
ii. SET ANSI_NULLS
ON
iii. SET ANSI_PADDING ON
Suggested Size:
@Table = 10 to 1000 (ensure no spill)
No temp tables
Error handling:
Just don’t – let the error bubble up
organically.
General:
No unnecessary load on system from 28th to
31st of Month, Month End work takes
priority!
Add to table tb_process2Kill if your process
is not critical.
Database environment – Reporting:
1. Comments: Add comments to your
changelog.
2. Query Guidelines:
i. Joins only 3 deep per statement.
ii. (NOLOCK) all queries.
iii. Only query data from yesterday – Data
at rest.
3. [Query Heavy] environment:
i. Create any indexes you need(Join and
where)
ii. Update indexes (<0.5gig)
4. Funnies:
i. Stand Alone DB – no Active Users
ii. Caching Job runs once a day [queries
will be killed]
5. Linked Servers – Use any that are already
there.
6. TempDB:
• Actively use temp DB for any transform.
It is huge and on super fast storage
7. Def. env. variables:
• SET QUOTED_IDENTIFIER ON
• SET ANSI_NULLS
ON
• SET ANSI_PADDING ON
• SET ARITHABORT ON
8. Suggested Size:
• No table variables
• Temp tables 10 – 100000
• Temp tables(with indexes) > 100000
9. Error Handling:
• Any Updates or inserts use both Try
Catch and sp_raiseLastError.
10.SSB Framework(ABC) in effect.
• All Procs must execute in <2 seconds
• SSB Procs are sp_procs_ABC_*