SQL Server Engine Tips

# Give Microsoft a piece of your (Datawarehouse) mind! @ Thursday, September 21, 2006 11:50 PM

Are you Datamart Builder with few bones to pick? Are your cubes too slow?Ok, so I can't do anything to...

Enjoy Every Sandwich

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Monday, September 25, 2006 11:43 AM

Please solve SQL 2000 problem 469591 ("When using sp_cursoropen with an Order By Clause we Generate an Inefficient plan ")

EHO

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Tuesday, September 26, 2006 11:31 AM

please ignore my posting from September 25, 2006 11:43 AM
wrong category

EHO

# Performance improvements for Katmai the next version of SQL Server @ Wednesday, September 27, 2006 3:02 AM

If you use SQL Server and have a great suggestion for performance improvements to the engine then post...

SimonS SQL Server Stuff

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Wednesday, September 27, 2006 2:30 PM

It would be really nice if you improved the sql processor to do better type casting.  I have taken to always doing explicit casts in all of my WHERE clauses to avoid the potential for very small queries.  An example is when doing a query with the where clause including a bit column.

SELECT *
FROM persons
WHERE enabled = 1 --enabled is a bit column

In this case the query will scan through each row in persons, cast the enabled column to an int and then compare it to the value 1.This can be very slow.  I always do a cast in this case
ie :WHERE enabled = CONVERT(bit,1)

But many people do not and this presents a problem.  I have noticed that SQL Server 2005 and 2000 behave very differently here.  Sometimes 2005 gets it right when 2000 gets it wrong, and sometimes 2000 gets it right when 2005 gets it wrong.

This just seems like a really easy optimization.

Martin Ritchie

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Thursday, September 28, 2006 9:34 AM

Can we have some unsigned int datatypes?

Dave

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Thursday, September 28, 2006 10:22 AM

Can we have some unsigned int datatypes?

Dave

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Thursday, September 28, 2006 2:03 PM

Not sure if I can call this as DW improvements.  But for sure I can say, if you guys can provide a URL where you guys can post "Case Studies" explicitly describing

1. Nature of Problem
2. What was accomplihsed
3. Technology used
4. What was the performance growth
5. User base (# of users)
6. Network Topology
7.....

May be this information is missing across web & I have been searching a lot on this, but noluck

PP

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Thursday, October 12, 2006 9:54 PM

a) Can we have some unsigned int datatypes?

b) Can we have some unsigned tinyint datatypes?

c) Can we have some unsigned smallint datatypes?

d) seperate date and time datatypes

e) ability to remove custom datatypes from a large existing database easily

susie dba

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Thursday, October 12, 2006 9:57 PM

better mdx design-time tools

better mdx query support in ms access

able to backup natively to a compressed format

ability to save your database diagrams into another format so that you can print them and format them-- instead of buying erwin and spendning a month to recreate your model

simple data entry and reporting forms

ability to KEEP CONNECTIONS OPEN in .NET... we typically use @@SPID as a session identifier; and your stupid 'we cant keeep connections open' theory is a total PITA

aaron kempf

# SSIS autmation engine @ Thursday, October 26, 2006 11:04 AM

BI studio is a centralize tool for designning

SSIS package and everything

can we have an SSIS automation engine

which serves as a centralize engine

for managing and monitoring SSIS packages

an engine where we can deploy all our package

link the packages in specific order and

from there see which package has failed and what was wrong.

if something did went wrong the engine allows me to execute the next package in the link

or something that allows me to start anywhere

in the link of packages

from that engine we can see everthing that went wrong to that package or link of packages including things like server is down. tlog is full etc

wish for a centralize automation and monitoring tool for SSIS package which is

as powerfull as the Bi design studio.

thanks

joeydj

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Wednesday, December 20, 2006 12:29 AM

There's been some interesting questions by users on the SQL Server Engine Tips blog. While almost all of them seem to be off topic, there are some interesting ideas. One of the fun ones was from Dave asking "Can we have some unsigned int data types?" So assuming Dave is wanting unsigned integers for this reason, I created a blog entry on how you would

create unsigned integer user datatypes

in SQL Server 2005...

Julian Kuiters

# re: Top 5 relational data warehouse performance improvements you would like to see in next version of SQL Server @ Friday, April 04, 2008 3:34 AM

Pivot of one columns values with values in a second column defining the result sets column names.

I could limit a list of index seeks typed by values in one column all grouped by a second to a common parent to a single index scan for the second common parent id producing meta data column names for the existent values.

At the moment I need to seek specifically for each typed value even though a scan and return of all for the second parent is sufficient.

Reduced number of cached plans to reconstruct varying meta data views.

Reduced number of higher level index pages scanned to find the index page/s that contains all the rows I want.

Though the column list would be only deterministic given the database state.

Orcus