SmartLink
Data platform

Database performance tuning in Pakistan: cost, duration and evidence

Database performance tuning in Pakistan is bought at one of two moments. Month end has slowed enough that finance has started asking, or a report that used to take four minutes now takes forty. SmartLink Services does this work from Karachi on Oracle, SQL Server and PostgreSQL, and it begins with measurement rather than with settings. Below is the commercial side of it: what tuning costs at published market rates, how long it takes before anybody sees a faster report, and the decision that shapes the whole engagement, which is whether the fix belongs in the database or in the application sending it work.

Discuss this service
Method
Measure \u00b7 fix \u00b7 re-measure
Evidence
AWR / execution plans
Output
Before-after benchmark
Overview

Measure the wait before changing the setting.

Performance work attracts guessing because everybody has a theory. Add memory, rebuild the indexes, increase a parameter, buy faster storage. Occasionally one of those is right, and when it is, it is right by accident. The reliable method is duller and considerably faster: capture what the system is genuinely waiting on, rank the contributors by the time they consume, and fix from the top of that list downwards. It is slower to start and considerably faster to finish, because nothing gets changed on a hunch and nothing has to be undone later.

Evidence comes from the instrumentation the database already provides. Wait event data, workload repository snapshots covering the period that is actually slow rather than a quiet afternoon, execution plans for the statements that matter, and session history showing what was happening while a user was complaining. Where the complaint concerns a specific report or a specific hour, we instrument that window rather than sampling the system in general and hoping. A general sample taken across a week tells you about the week. It rarely tells you anything about the twenty minutes somebody complained about.

Every engagement produces a before and an after. A baseline is captured, changes are applied in small groups with a record of what changed and when, and the same measurement is then repeated the same way. That discipline matters because performance work generates confident claims, and a comparison against a recorded baseline is the only thing that reliably separates a real improvement from a quiet week. It protects the client as well. A tuning engagement with no baseline can claim almost anything, and the claims are usually made in good faith by people who have simply not measured.

Scope

What Performance tuning covers

Everything below is agreed in writing before any oracle & databases work starts, so both sides know what is in and what is not.

What the work covers

  • Wait event and AWR analysis
  • SQL execution plan review and rewriting
  • Index and statistics strategy correction
  • Memory, PGA and SGA sizing review
  • Batch and month-end job scheduling review
  • Application-side query pattern recommendations

What you get at handover

  • Baseline performance benchmark
  • Prioritised findings with expected gain
  • Applied change log
  • Post-change benchmark comparison
  • Ongoing monitoring recommendations

Typically involves

SQL Tuning Advisor Query Store Grafana
Discuss this service
01

Why plans change

A query that ran in seconds for a year and now runs for twenty minutes has rarely been rewritten. The plan changed. The optimiser made a different decision because the statistics describing the data changed, or because they failed to change when the data did, and the estimate it was working from stopped resembling the table in front of it. Chasing the query text in that situation wastes days. The question worth asking first is what the plan used to be, when it changed, and what else changed around it.

Common causes repeat across estates. Statistics gathered while a table was empty between a truncate and a load. A column with heavily skewed values where the optimiser assumes even distribution. A date range predicate reaching past the highest value the statistics know about, so the estimated row count collapses and a nested loop gets chosen for a large result. Bind variable peeking producing a plan that suits the first value and nothing after it. Each of these leaves a recognisable signature.

The fix depends entirely on the cause, which is why identifying it first is not a formality. Sometimes the answer is a change to how and when statistics are gathered. Sometimes it is a histogram, or the removal of one that is misleading. Occasionally it is stabilising a plan deliberately, which we treat as a considered decision rather than a first response, because a frozen plan will not improve when the data changes again. That trade needs recording somewhere visible.

  • Plan history examined to establish when the plan changed and what it changed to
  • Statistics gathering strategy reviewed, including its timing relative to bulk loads
  • Skew and histogram handling checked on the columns that appear in predicates
  • Bind variable sensitivity considered where one plan suits some values and not others
  • Plan stabilisation used deliberately and recorded, never reached for as a first response
02

Missing indexes and costly ones

Missing indexes are the visible problem and only half of it. Every write pays for the indexes that already exist, and a table carrying a dozen of them, several overlapping and two never chosen by any plan, has a measurable insert and update cost that nobody attributes to indexing because the symptom appears in a completely different part of the day. Overnight loads slow down, a batch window stretches, and somebody proposes faster storage. The indexes are never mentioned, because the query everybody worried about is now fast.

We look in both directions. Usage monitoring identifies indexes no plan has selected across a representative period, which produces a candidate list rather than a delete list, since a quarterly report may depend on exactly one of them. Overlapping indexes where one is a prefix of another can often be consolidated. And the access paths lacking support show up plainly in the plans, usually as a full scan on a large table inside a loop.

Index changes need a real workload to be judged against. A composite index that improves one query can slow a nightly load enough to matter, and the only honest way to know is to measure both sides. We change in small groups, keep a log of what was applied and when it went in, and check the effect on write performance as carefully as the effect on the query that prompted the change. Reads are easy to celebrate and writes are easy to forget.

  • Index usage monitored across a period long enough to include periodic and month end work
  • Overlapping and redundant indexes consolidated rather than left to accumulate
  • Write cost assessed alongside read benefit before any index is added
  • Full scans inside nested loops on large tables treated as a priority finding
  • Every index change logged, so a later regression can be traced to what was applied
01

What database performance tuning costs in Pakistan

Tuning is bought in one of two shapes, and choosing the wrong one is the most common way of overpaying. The first is a fixed assessment: measure the workload, produce a ranked list of findings with the expected gain against each, and stop there. The second is hours against that backlog once you have decided which findings are worth acting on. Market hourly rates in Pakistan run PKR 3,500 to 8,000 for full stack technical work, with senior specialist time at the top of that band and junior work published at PKR 500 to 1,000. Database performance tuning is senior work, since the value is in reading the evidence rather than in applying the change.

The question you bring decides the price more than the estate does. A specific complaint costs less to answer than a general one. Somebody who says the payment run must finish before six in the morning has defined the engagement. Somebody who says the system feels slow has bought a discovery exercise instead, and a discovery exercise on a month end with eleven slow steps is a different size of job from one slow report. Count the distinct complaints before asking for a quotation.

Three practical things move the effort. Whether the application can be changed at all, because a packaged product whose vendor owns the code narrows the available fixes considerably. Whether a non production copy exists at anything like production volume, since a plan that only reproduces on live data forces every experiment into a change window. And whether diagnostic data has been retained, because where none exists the first job is to start collecting it, and that costs a month before any finding is possible. On Oracle, the diagnostic and tuning packs are licensed separately, and entitlement is verified with Oracle rather than assumed by us. Everything above is market context. A real figure follows discovery.

  • A specific target named before quoting, since a defined complaint costs less than a vague one
  • The assessment sold as a fixed piece of work, with a ranked findings list as its deliverable
  • Application changeability established early, because a vendor owned product narrows the options
  • A production sized non production copy sought, so experiments do not need a change window
  • Diagnostic pack entitlement verified with Oracle before anything relying on it is quoted
02

How long performance tuning takes

First findings arrive quickly. With diagnostic data already being retained, a week is usually enough to name the top waits, the heaviest statements and the jobs colliding with each other. Where nothing has been collected, add a month to that, because a workload has to be observed before it can be characterised and nobody can characterise it from a screenshot taken during the slow afternoon.

Applying the fixes runs to the same clock as any other change. Reported delivery timelines in Pakistan put a focused scope at six to twelve weeks, and most tuning engagements sit comfortably inside that. An index on a large table needs a window. A statistics strategy needs a cycle to prove. A change to a scheduling order needs a night to run before anybody knows whether it helped. None of those three is brought forward by adding people to the engagement.

Month end is the honest complication and it deserves stating early. It can only be watched once a month, so an engagement aimed at a slow close has a natural rhythm of observe, change, wait, measure, and that rhythm cannot be compressed by adding people to it. Two closes is a realistic horizon for a month end problem rather than two weeks. Application side fixes stretch further still, since they queue behind a release cycle, and behind a vendor's release cycle where the product is packaged. We publish a before and after benchmark for each change rather than a summary at the end, so a decision to stop is available at any point.

  • A week to first findings where diagnostic data is already retained, a month where it is not
  • Index and statistics changes scheduled into windows rather than applied opportunistically
  • Month end problems measured across two closes, since a close cannot be rehearsed faster
  • Application side fixes planned around the release cycle that will carry them
  • Before and after figures published per change, so stopping early stays an option
03

Tuning the database or changing the application

Almost every engagement reaches this fork, usually in the second week, and the answer decides both the cost and who pays it. Database side fixes are cheap, quick and reversible. An index, a statistics strategy, a stabilised plan, memory sizing, a partition, a rescheduled batch job. None of them needs a code release, most can be undone in minutes, and on a neglected estate they frequently deliver the largest single improvement anybody sees. Their limit is real though. No index fixes a screen that issues four thousand queries to paint one page, and no amount of memory rescues a report that asks for the whole ledger and discards most of it in the browser.

Application side fixes are slower, more expensive and permanent. Pagination instead of a full fetch. A query lifted out of a loop. A caching decision. A batch size chosen deliberately rather than inherited from a tutorial. A heavy report moved off the transactional database entirely. These cost a release, a test cycle and developer time, and where the product is packaged they cost a support case and a wait. What they buy is a gain that survives the next doubling of volume, which the database side fix often does not.

More hardware is the third option and it deserves an honest hearing rather than a reflex. It is the right answer when a system is genuinely at a resource limit and no change window exists for anything else, and it is the wrong answer dressed as a decision when nobody has measured. What it buys is time. The same query will exhaust the larger machine at higher volume, on a date somebody could have predicted.

We decide it with arithmetic rather than preference. Measure first. Then ask what the fix is worth: a nightly job finishing at half past seven costs the depot an hour of loading every morning, which justifies a release, while a report run twice a year by one person justifies an index and nothing more. Where the slow code belongs to a vendor, we produce the evidence for their support case, including the plan and the timings, and we do not modify their product. Where the honest finding is that the application is the problem, we say so and put it in writing, even when the estate is the thing we were hired to change.

  • Database side fixes applied first, since they are quick, cheap and reversible
  • The ceiling of a database only fix stated plainly rather than discovered later
  • Application changes justified by what the delay costs the business each day
  • Additional hardware treated as bought time, with the date it runs out estimated
  • Evidence packaged for a vendor support case where the code is not yours to change
How we deliver

Delivering Performance tuning

Order matters more here than anywhere else. Monitoring goes in before anything is touched, because a tuning claim with no baseline behind it is an assertion rather than a result.

  1. 01

    Discover

    Baseline the estate first: versions and patch levels, parameter drift, who holds which privilege, what the alert log has been saying for months, which query plans have flipped, and whether a restore was ever actually performed.

  2. 02

    Blueprint

    Character set, block size, storage layout and partitioning keys are chosen once and written down, with the recovery point and recovery time the business is willing to accept stated in hours, not adjectives.

  3. 03

    Build

    Instances are created from a scripted build so a second one is identical, with Data Guard standby, RMAN catalogue, backup schedule and monitoring configured before a single application schema is loaded.

  4. 04

    Test

    Testing here means a restore. A full RMAN recovery to a point in time on separate hardware, timed, with the switchover to standby rehearsed and the output written up as evidence somebody can read.

  5. 05

    Go live

    Cutover is a migration window with a stated fallback: the old instance stays intact and reachable until the new one has carried a full month-end and the reconciliation has been signed.

  6. 06

    Run

    Quarterly patching on a rehearsed route, monthly capacity and health reporting, restore tests on a schedule, and privileges withdrawn in stages once audit evidence shows which application actually uses them.

Working together

Before and after, or it did not happen

Every engagement ends with the same measurement it started with, run the same way, on a comparable period. Baseline, prioritised findings with the reasoning attached, a log of what was applied, and a repeat measurement. Where a change did not deliver what we expected, that goes into the report as well, because the alternative is a document claiming every intervention worked, which is worth nothing as a record and less as a reference.

The other commitment is that we prioritise by time consumed rather than by what is interesting to work on. The most satisfying problem to solve is rarely the most expensive one to leave alone. Ranking by measured wait time keeps the work honest and keeps the effort pointed at the hour finance loses every month, rather than at the query that happens to irritate a developer.

Credentials

Accreditations behind Oracle & databases

Accreditation questions get technical in this practice, so here is what each partnership actually covers in database work.

Oracle

Partner

Oracle Database from 11g through 23ai, including RAC, Data Guard, RMAN and the quarterly update route. We flag separately licensed features before enabling them during any investigation.

Microsoft

Partner

SQL Server administration alongside the Oracle work: Always On availability groups, backup verification, index and plan analysis, and Azure as the hosting option when the hardware refresh is due.

Google

Partner

PostgreSQL on Cloud SQL for teams who want a managed engine, with backups landing in Cloud Storage and the same monitoring, restore testing and privilege review we apply to Oracle.

FBR digital invoicing

Compliant integrations

Invoice records submitted to the FBR system have to be retrievable years later. That is a retention, indexing and audit trail problem in the database, and it is where we get involved.

HIPAA

Compliant practices

Health data at rest is encrypted, production copies used in test are masked, auditing is enabled on the objects that hold it, and we work under a business associate agreement.

Client words

What Oracle & databases clients say

Comments from people who run oracle & databases systems day to day.

  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
Questions

Questions about Performance tuning

It is usually bought as a fixed assessment producing a ranked findings list, followed by hours against whichever findings you accept. Market hourly rates in Pakistan run PKR 3,500 to 8,000 for senior technical work, with junior work at PKR 500 to 1,000. A specific target costs less to answer than a general complaint, so name the report or the job before asking for a figure. We quote after discovery.

Where diagnostic data is already retained, first findings take about a week and the quick wins can often be applied inside the same window. Where nothing has been collected, add a month for observation. A month end problem is different: it can only be watched once a month, so plan for two closes rather than two weeks before the improvement is proved.

Frequently, and that is where we start. Indexes, statistics, plan stability, memory sizing, partitioning and batch scheduling need no code release and can be reversed quickly. There is a ceiling. A screen issuing thousands of queries to paint one page cannot be fixed below the application, and when that is the finding we say so rather than tuning around it.

Something changed, it just was not a release. Data volume grew past the point where a plan stayed sensible. Statistics went stale or were refreshed at the wrong moment. A new report was scheduled into a window that already had a job in it. A parameter moved during a patch. The alert log and the retained diagnostic history usually name the week it started.

Read access to diagnostic data at minimum, since the workload only exists there. Changes are proved on a non production copy first where one at realistic volume exists, and where it does not, that is itself a finding worth acting on. All changes are applied through your change process with a stated rollback, and we record what was applied and when.

Then the fix may not be ours to make, and pretending otherwise wastes your money. We measure the statement, capture the execution plan and the timings, and package that as evidence for the vendor support case, which usually moves faster than a general complaint does. Meanwhile we apply whatever database side improvement is available and safe underneath their product.

More in Oracle & databases

More Oracle & databases services

Data platform

Oracle database management

Day-to-day administration: patching, backups, monitoring, capacity and incident response.

Open service page → Data platform

Oracle database building

New database architecture: sizing, schema design, high availability and standards, built to be handed over.

Open service page → Data platform

Database security & hardening

Privilege review, encryption, auditing and masking, reducing what an incident can reach.

Open service page → Data platform

Data warehouse & BI

A reporting layer separated from your transactional systems, with numbers that reconcile.

Open service page →

Month end taking longer every quarter?

Tell us what you run today and where performance tuning is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All oracle & databases