Forum posts to 'Frequently Asked Questions'

I'm not receiving the email with the download link after pressing the download button, what should I do?

Inbal — Sun, 15 Nov 2009 14:48:49 +0000

Spam filters may be preventing our email from reaching your mailbox.
Please add "webmaster@dbsophic.com" to your whitelist and press the download button again.
If you have logged out and do not know the password to your DBSophic account, please go to the Log in page and select "I've lost my password", and an email will be sent to you with a link which will enable you reset your password.
Then return to the Download page and download Qure again.
If the problem persists, please contact support@dbsophic.com and one of our experts will assist you.

Posted to: I'm not receiving the email with the download link after pressing the download button, what should I do? Show Thread | Post Reply

Can Qure help me optimize the performance of ANY database?

Ami — Thu, 19 Mar 2009 06:40:47 +0000

Qure can help you optimize the performance of almost any database.
Qure’s recommendations have proved to be extremely effective, yielding significant performance improvements, on “real world” production databases in ~ 8 out of 10 databases.
About 2 out of 10 databases, experienced less dramatic improvements and in very few cases, no or very little improvement was achieved.
Our tests and careful manual analysis of these databases revealed that the databases that gained the least from Qure’s recommendations were either highly optimized to begin with or that the main causes of the slow performance were rooted in issues such as design and coding techniques beyond Qure’s current scope of analysis.
We are constantly working on expanding and perfecting Qure’s analysis algorithms with every new version of Qure to increase the scope of Qure’s analysis.

Posted to: Can Qure help me optimize the performance of ANY database? Show Thread | Post Reply

Should I prepare anything in advance before using Qure?

Ami — Thu, 19 Mar 2009 06:39:59 +0000

Yes.
The minimal requirement is to prepare a SQL Server trace according to the provided trace template.
The templates are located under the "TraceTemplates" folder in the Qure installation folder and can also be downloaded here.
The trace should be performed long enough and at the right times to faithfully represent the full range of activities of the database applications.
For more information on how to perform an effective trace, read the chapter ”Preparing a Trace File Using SQL Profiler” in the Qure user guide.
In addition, Qure requires some prerequisite for installation such as .Net framework 3.5 SP1 and SQL Server client tools.
For more details, read the chapter ”Installation Prerequisites” in the Qure user guide.
You must use a dedicated server with a restored copy of the production database for both the analysis and the benchmark processes.
For more information on the analysis server, read the chapter “Preparing the Analysis and Benchmark Server” in the Qure user guide.

Posted to: Should I prepare anything in advance before using Qure? Show Thread | Post Reply

Will Qure’s analysis process have any effect on my production system?

Ami — Thu, 19 Mar 2009 06:39:08 +0000

Qure’s analysis process is no longer a read only operation.
Qure’s analysis process automatically applies changes to the database and should NEVER be performed on a production environment.

Posted to: Will Qure’s analysis process have any effect on my production system? Show Thread | Post Reply

How long does the analysis processes take?

Ami — Thu, 19 Mar 2009 06:38:03 +0000

It is very difficult to predict the duration of either the analysis or the benchmark processes. The duration depends on many factors, the main ones being the:
> Total number and complexity of the trace file events
> Number of unique batches in the trace file
> Number of database objects
> Number of tables and the number of rows in tables
> Size and complexity of the code in the programming objects
> Resources available to the database server machine
> Resources available to the machine where Qure is installed
> Number and type of batches and recommendations tested during benchmark

Posted to: How long does the analysis processes take? Show Thread | Post Reply

How often should I perform a database analysis with Qure?

Ami — Thu, 19 Mar 2009 06:34:56 +0000

There is no definitive answer to this question.
We recommend that you perform a new database analysis at least whenever a new version of Qure is released or when the database and/or the applications that use it have changed either in structure, code, data volumes or usage patterns.

Posted to: How often should I perform a database analysis with Qure? Show Thread | Post Reply

Do I need to purchase a license every time I want to view a report?

Ami — Thu, 19 Mar 2009 06:34:14 +0000

No.
Once a full analysis has been performed (running a full analysis requires a license), you are able to view it and work with the recommendations report, the benchmark, apply and all other Qure features unlimitedly.
Since the license information is embedded in the analysis file (*.quan), you can even copy the file to another computer where Qure is installed (licensed or not) and use all of Qure’s features.
Performing a new full analysis requires a new license.
The same applies to a trial (unlicensed) analysis.

Posted to: Do I need to purchase a license every time I want to view a report? Show Thread | Post Reply

The benchmark shows that some batches’ performance has degraded after applying the recommendations. How can that be?

Ami — Thu, 19 Mar 2009 06:31:45 +0000

You need to first consider what really constitutes “performance degradation”.
The benchmark provides you with 5 different parameters to measure each batch’s performance before and after applying Qure’s recommendations.
These parameters are Duration, CPU, Logical reads, Physical reads and Writes.
Since SQL Server profiler, the tool that most database administrators use for performance tuning, does not provide the physical reads parameter, it is common for DBAs to estimate a batch’s performance by logical reads only. This may be somewhat misleading.
Consider, for example, a query that joins tables A and B using a hash join algorithm.
The addition of a proper index for the join can cause a change of the execution plan from hash join to nested loops.
This may result in a higher number of logical reads since the pages are accessed more than once, unlike the single access patterns used in hash algorithms.
Actually, the efficiency of the query may have improved significantly since these extra “logical reads” are mostly memory accesses.
Although the logical reads may have increased, in most cases physical reads decrease, CPU consumption is reduced and less memory or additional IO operations are consumed since no hash tables are required.
Another common issue that can cause misleading benchmark results is concurrent activity on either the server that hosts the benchmark database, or the client computer running the Qure benchmark, or the network infrastructure connecting the two.
Concurrent activity may delay the completion of the processing of the benchmarked batches due to disk, CPU, network or memory congestion.
This may result in an increase in the measured duration of the batch.
In most cases, if you see that duration has increased but other parameters such as physical reads and CPU have improved, you can reasonably assume that this is due to some concurrent activity.
It is important to note that all batches are executed serially; therefore blocking locks do not affect duration.
In rare cases, applying Qure recommendations may degrade the batch’s performance.
The two cases that we have encountered so far where this has happened are rewrites and new index creations.
A rewrite that may yield significant performance improvement in one scenario can cause a performance penalty in another, depending on numerous factors, some of which are beyond the current analysis scope of Qure.
The addition of a new index may cause the SQL Server optimizer to use it in error, based on a wrong estimation of its efficiency for a particular query.
For example, a query plan that used a table scan before the addition of an index may change to use an index seek and lookup after the index is created.
In some cases, the optimizer wrongly estimates, during compile time, that a certain number of rows satisfy the query’s filters when, in fact, a much larger number of rows are returned at run time causing a severe performance penalty due to excessive lookup operations.
This may negatively affect the query’s performance.
For both the above and similar cases, Qure provides you with the accurate actual measurements of the benchmark so you can use your knowledge and skills to further reject recommendations that you find inefficient.
We are proud that these cases are very rare.
If you do encounter such a case, where Qure’s recommendations have degraded a batch’s performance, we would highly appreciate your contacting support@dbsophic.com and providing all the relevant details so we can work on improving Qure and further minimizing such cases in future versions.

Posted to: The benchmark shows that some batches’ performance has degraded after applying the recommendations. How can that be? Show Thread | Post Reply