Showing posts with label hii. Show all posts
Showing posts with label hii. Show all posts

Friday, March 9, 2012

Faster SQL query

Hi!
I M basically an application developer & use simple sql queries in my programmings. I do not have much idea abt tuning/auditing part & thatswhy i m unable to answer them properly in my interviews. Can anybody give me some tips???

Question 1:
In a stored procedure, One SELECT stmt is there & depending upon the @.rowcount, it updates around 14000 records which is also written inside this stored procedure. Instead of writing this way, there is some other way which is faster than this. Can anybody tell me the correct way?

Question 2:Can anybody give me few examples like this?? I need them desparetly.

Thanx. Bye.::I M basically an application developer & use simple sql queries in my programmings. I do
::not have much idea abt tuning/auditing part & thatswhy i m unable to answer them
::properly in my interviews. Can anybody give me some tips???

Get a good beginner book into SQL, like "SQL for Dummies" (no pun intended, the dummies books are nowmally very nice).

::In a stored procedure, One SELECT stmt is there & depending upon the @.rowcount, it
::updates around 14000 records which is also written inside this stored procedure. Instead of
::writing this way, there is some other way which is faster than this. Can anybody tell me the
::correct way?

No. Because you do not give enough information to advice on a better way.

::Question 2:Can anybody give me few examples like this?? I need them desparetly.

I really suggest some introductory books about how SQL works. Simple queries do not cut it.|||Let me give the skeleton of the store proc:

select * from tab1
if @.rowcount>1
update table2 set col1="asadsasasa"
end if

That person was asking me "by updating 40000 records in this manner, it will be quite slow". So, what is the faster way?

thanx for ur advice... i w'll go thru one such book.

Bye.|||Another rubbish question, the original question that is. What does "updating 40K records" mean? Are they saying you'd call this proc 40K times? I assume they're talking about an update with a join, but the question is just awful. The proc shown here would always just update the same thing so an update join would be no better? Madness!|||::That person was asking me "by updating 40000 records in this manner, it will be quite
::slow". So, what is the faster way?

The issue is the

::select * from tab1

which retrieves the rows.

a better way is along the lines

select count(*) from tab1 (hm, how do syou select into a variable- i Havenot done sp's for more than a year)
if (variable) > 1

the select count(*) does not retrieve the values.

You should really get:

* SQL for dummies

THEN

SQL for Smarties from Joe Celko|||Well done thona for translating the question! If you're right then you'd be better of with an "exists"

If exists(select * from tab1)
update table2 set col1="asadsasasa"

Although I still think the wording of "update 40000..." is mighty odd.|||::If you're right then you'd be better of with an "exists"

Yes, I realized this, too, once it was posted.

Bout someone else was right - the original question is not formulated good.|||Thanx everybody & extremely sorry for these type of questions. But hope u all understand my problem. Actually all these questions are asked by somebodyelse. So, thanx for ur cooperation.

Yes, Exists & Count are better option for the "SELECT" stmt. But he was stressing more on the "UPDATE" stmt which is updating 14K records after getting the @.ROWCOUNT.

SO KINDLY COOPERATE AGAIN.

THNX EVERYBODY.|||If you really want to change the same col in 40K records there really isn't much else you can do. Perhaps turn off the indexing and put it back at the end or something but I think that's reaching a bit. If that represented the entire table then I 'spose you could argue that truncating the table and then inserting might be a tad quicker but again that sounds a mighty complicated answer for such a strange question. Plus you'd get into trouble if you wanted to rollback. Are you sure there isn't something missing from the original question?|||Hi PKR!
thnx for ur cooperation. There is no other clue for u/me. He was only stressing on that point only.(i.e. updating 14k records in this manner will take lot of time).

Do u have any idea abt the followings:
1. Is there any possibility to fire a trigger for updation?
2. Is a nested stored proc will be a better option?

Thanx again.

Waiting for reply...|||I already said once, I repeast it now:

get an introducotry book into SQL. Most of your questions are simply a result of not really having a deep understanding of the language. You need to get into set oriented mood to achieve anything in SQL in a fast way.

::1. Is there any possibility to fire a trigger for updation?

Did you look at the documentation of the CRATE TRIGGER statement? It would answer this question in less time than posting.

::2. Is a nested stored proc will be a better option?

This sentence makes no sense grammar wise, sadly.

Nested SP's should be used when necessary. Calling a nested SP instead of making a set operation is a beginner error, though - a proper SQL Server (count oracle out of this for certain things) works SET oriented. Replacing a set command with a nested SP called in a loop is NOT a good way to achieve something.|||Hi!
Sorry ... & thanx for ur valuable advice. I'll do as u said.

Bye|||Hello Thomas!

Sorry for disturbing u again. AS per ur advice, i went thru the fundas.

It seems that fellow wanted to ask me the alternative of "Runtime Query Handling" in a stored proc. As it will be slow if we use the runtime queries ....

So, cud u pls. tell me if any alternative approach is there. I think only alternative approach is to do these things in our application program instead of stored proc.

Kindly advice.

Reagrds,

Lita.|||::It seems that fellow wanted to ask me the alternative of "Runtime Query Handling" in a
::stored proc.

Alternative of WHAT?

Puting three terms noone knows besides you into paranthesis does not make it common knowledge.

What do you mean?|||Interesting that neither "Run-time Query Handling" nor "Runtime Query Handling" return a single hit from Google. Sounds like an interviewer who doesn't have a clue and is trying to throw a curve.

Faster ODBC connections wanted on W2K

Hi
I've been developing an app that use ODBC connections to connect to a database server (SqlServer, MySql or Oracle for the moment).
I noticed that SqlServer connection from a client was between 5 and 6 time faster with a server installed on W2K professional than on W2K Server.
These 2 servers have similar hardware and the same version of SqlServer installed.
The only ODBC parameters that changes on the client is the IP adress of the server.
Do you know what is the problem ?
Do you have some software solutions to get a faster SqlServer ?Need more information.
-Is the client running an a third box or one one or both of the sql-servers?
-Are the databases on either identical? same idnexes, etc?
-Is either sql-server set to use a different amt of ram? Check in the server properteis in em.
-Is either sql-server database set up on a different physical disk than the other? is it the same disk as the os or swapfile?
-Has either server been up and running for a while? If either server has already cached the requested data, it will be much faster. Try them both again after a fresh restart.
-Have you tried OLE-DB instead of ODBC? It tends to perform better.
-Are the two sql-servers on the same network or is one on another subnet or in some other location?

...|||Thank you for your answer.

You wrote :
-Is the client running an a third box or one one or both of the sql-servers?
The client is running on a third box.

-Are the databases on either identical? same idnexes, etc?
The databases are identicals (tables and indexes generated by the client itself)

-Is either sql-server set to use a different amt of ram? Check in the server properteis in em.
I think SqlServers installations are standards so they should use the same amount of memory but how can I check it ?

-Is either sql-server database set up on a different physical disk than the other? is it the same disk as the os or swapfile?
I don't understand your first question but It's the same HD than the OS (installed on C:\MSSQL7)

-Has either server been up and running for a while? If either server has already cached the requested data, it will be much faster. Try them both again after a fresh restart.
Even if the servers have just been started, the result is that it's slower on W2K Server.

-Have you tried OLE-DB instead of ODBC? It tends to perform better.
I have to use ODBC

-Are the two sql-servers on the same network or is one on another subnet or in some other location?
They are on the same network.

As you can see, there is no reason to have my app being slower with W2K server than with W2K pro but i'm not crazy, it's 5 or 6 time slower !
I'm sure that the problem is concerning W2K Server itself : a security option to disable, a service to stop ... I don't know ... I'm just a developer ... not a W2K expert. The problem occured on 2 different PC using W2K Server and I never encountered the problem on W2K pro.

On W2K Server, I check that background services was prefered to applications, I try to set the network card to use 'Full Duplex' but the problem is the same.

Thank you for your help.|||Hmmmm This is curious...

- Regarding the disk setup, my thought was that perhaps the data files were on a seperate physical disk from the OS/swapfile on one machine or the other, but that appears to not be the case.

- Regarding the memory settings, in Enterprise Manager, right click on the server and select properties, select the memory tab and check that the settings are identical for both systems.

- Have you checked to make sure that both ODBC connections are configured to use the same network library? You can do this by clicking on the 'client configuration' button during the DSN setup.

- I would run a profiler trace to watch the processes run and see if they are taking the same amount of time to process in SQL Server and if the problem might be with the network transmission. You can then capture the queries being used, paste them into Query Analyzer and get an execution plan on each sql-server to see if they're parsing the query the same way on each.