Re: SQL Server extremely slow
- From: "bcap" <bcap@xxxxxxxxxxxxxx>
- Date: Tue, 10 Mar 2009 09:20:10 -0000
It's a common misconception that upsizing to SQL Server will give an
immediate performance boost, and it's very common for some queries to
perform worse (sometimes massively worse) when you do upsize.
This isn't because there is anything fundamentally wrong with architecture.
An Access application using a SQL Server back-end via ODBC linked tables is
capable of thoroughly outperforming an application with an mdb back-end, but
only if:
(i) the Access application with the mdb back-end was performing poorly (if
it was performing well anyway, then there isn't much scope to improve it!)
(ii) the Access application was performing poorly for the kind of reasons
which will make it worthwhile to upsize (which basically boils down to it
having "outgrown" Access in terms of user numbers and the load it imposes on
the network)
(iii) the Access application is reasonably well designed (a poor design is a
poor design regardless of the database engine)
(iv) you are prepared to selectively tune and re-design the application to
get the best out of the Access/SQL Server architecture.
Point (iv) means understanding this: when you use SQL Server as the back-end
with ODBC linked tables, running any query involves TWO query engines:
Access/Jet, and SQL Server. Access/Jet queries are "translated" into SQL
Server queries, for the server to execute and return a result set. Often
this works very well. Almost as often it doesn't, either because you have
done something in the Access/Jet query which is fundamentally incompatible
with SQL Server, or because it's simply too complex to be "translated". In
these circumstances, large quantities of data will be hauled out of the
database and shunted across the network so that Access/Jet can execute the
query locally. Performance nose-dives horribly.
The good news is that, for any one query, this is usually easily rectified,
using techniques such as:
- alter the Access/Jet query so that it *can* be executed at the server
- rewrite it as a "passthrough" query i.e. a native SQL Server query
- create a view on the server and link to it as though it were a table.
The bad news is that, in a large application, you might find yourself doing
this a lot...
"Niranjan" <nhiras@xxxxxxxxx> wrote in message
news:6f900e82-66cf-4407-9d6e-bfed0566dea2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi everyone.
I upsided my Access 2000 backend database to SQL Server. Everything
works, however, we have a remote site where a couple of people access
the database. That site is extremely slow. It takes about 5 minutes to
run a report that normally took less than 30 seconds on the Access
backend connected to the remote site.
The backend is connected via ODBC. The front end is still Access. The
backend SQL Server database does not have any stored procedures or
triggers.
The connection to this remote site is thru trust created between the
domains. They also use Opt-e-man service.
Any ideas are appreciated.
.
- Follow-Ups:
- Re: SQL Server extremely slow
- From: David W. Fenton
- Re: SQL Server extremely slow
- References:
- SQL Server extremely slow
- From: Niranjan
- SQL Server extremely slow
- Prev by Date: Re: AK2 Crashes
- Next by Date: Re: Advanced Access - Book Recommendations
- Previous by thread: Re: SQL Server extremely slow
- Next by thread: Re: SQL Server extremely slow
- Index(es):
Relevant Pages
|