SmartLink
Data platform

Databases that are documented

Oracle database support in Pakistan is usually bought under pressure. A DBA has resigned, a restore has never been tried, or month end has slowed enough that finance has started asking. We work from Karachi across Oracle, SQL Server and PostgreSQL, and the first deliverable is always the same: a written baseline covering what runs, how it is configured, who can reach it and what recovery looks like when it is tested rather than assumed. After that the work divides into keeping the estate healthy, keeping it fast and keeping it defensible. This page answers the commercial questions first, because those are the ones buyers ask before anything technical.

Discuss this practice
Versions
Oracle 11g to 23ai
Coverage
Business hours or extended
Reporting
Monthly health report
Recovery
Restore tested, not assumed
Overview

Your database state, written down

A surprising number of production databases are understood by exactly one person. The parameters were tuned years ago for reasons nobody wrote down, the backup job reports success without anyone confirming a restore works, and privilege lists have grown by accretion rather than design.

Our database work starts by writing the baseline down. What is running, how it is configured, who can reach it, how it is backed up and what recovery actually looks like when tested rather than assumed. That document becomes the reference point for everything afterwards.

From there the work splits into three streams that tend to arrive together: keeping it healthy through monitoring and patching, keeping it fast through evidence-based tuning, and keeping it defensible through privilege review, encryption and auditing.

Scope

What Oracle & databases covers

Engagements range from a one-off health check or hardening review through to full managed administration.

What the work covers

  • Instance monitoring, alerting and incident response
  • Patch and quarterly update planning with a rollback path
  • Backup verification and periodic restore testing
  • New database architecture: sizing, schema, high availability and standby
  • Privilege review, encryption, auditing and data masking
  • Performance diagnosis with evidence, then targeted tuning

What you get at handover

  • A documented database baseline
  • Backup and restore test evidence
  • Monthly health and capacity report
  • Privilege and encryption review with remediation list
  • Incident log with root-cause notes

Typically involves

Discuss this practice
Services in this practice

Every Oracle & databases service

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 standby.

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

Performance tuning

Slow reports and month-end bottlenecks diagnosed with evidence rather than guesswork.

Open service page → Data platform

Data warehouse & BI

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

Open service page →
01

What a first engagement establishes

A first database engagement is almost always an assessment, and it is worth being precise about what an assessment can see. With read only access to the instance, the configuration, the alert log and the backup catalogue, a great deal becomes visible within days: parameter drift, unpatched versions, privileges granted long ago to accounts nobody recognises, jobs that fail quietly every night. What is not visible is intent. Why a parameter was set, which application depends on a particular behaviour, and who decided a table should never be indexed.

So the assessment runs alongside conversations rather than instead of them. The people who know why usually still work somewhere in the organisation, or their reasoning survives in an old change record. Recovering that context early is cheap. Reconstructing it after the person leaves means inferring intent from the system itself, which is slow and produces answers that are plausible rather than correct. Where a departure is already scheduled, that window becomes the most valuable part of the engagement.

The output is a written baseline and a ranked list, and the ranking is where judgement is applied. An unverified backup and a missing index are both findings, but only one of them can end the organisation. We separate what threatens recovery, what threatens security, what threatens performance and what is merely untidy, then say plainly which items we would fix this month. Being told that most of the list can safely wait is a legitimate and reasonably common outcome.

  • Read only assessment access agreed in advance, with a named technical contact
  • Configuration intent recovered from people and change records while it is still available
  • Findings ranked by consequence rather than presented as an undifferentiated list
  • A clear statement of what an assessment cannot see without application knowledge
  • An explicit decision on which findings are deferred, recorded with a review date
02

Architecture choices that outlive the people who make them

Certain build time choices are effectively permanent. Character set is the classic example: choose one that cannot represent a script the business will later need, and the remedy years afterwards is a migration of the entire database rather than a change of setting. Storage layout, block size and the decision to separate data, index and temporary space follow closely behind. None of these is difficult to get right at the beginning, and all of them are disproportionately expensive to revisit once several years of production data have accumulated.

Partitioning strategy and high availability topology form the next tier. A partitioning key chosen for the way reporting works today will constrain how data is archived and purged for the rest of the system's life. Standby configuration, including whether Data Guard runs in maximum availability or maximum performance, is a business decision about acceptable data loss expressed in technical vocabulary. We put those choices in plain language, with the recovery point and recovery time each option implies, and ask the business to sign the answer.

Feature use carries a commercial consequence that surprises people. Several capabilities in the enterprise database world are separately licensed, and enabling one during a performance investigation can create an entitlement question months later. We flag those before anything is switched on and check what your agreement already covers. Verifying entitlement is a contractual matter between you and the vendor or your reseller. We do not resell licences, so nothing we recommend earns us a margin in either direction.

  • Character set, block size and storage layout decided before the first production load
  • Partitioning keys chosen with archiving and purging in mind, not only reporting
  • Recovery point and recovery time objectives stated by the business and signed
  • Separately licensed features flagged before they are enabled during any investigation
  • Entitlement verified with your vendor or reseller, with no commission on our advice
01

Oracle database support pricing in Pakistan

Typical market rates in Pakistan run by seniority rather than by product. Published hourly figures put junior engineering work at PKR 500 to 1,000 an hour, full stack work at PKR 3,500 to 8,000, and senior specialist work at the top of that band, up to PKR 8,000. Database administration is specialist work, so the upper end is the honest reference point rather than the average. The same skills billed internationally are quoted at USD 15 to 50 an hour, and premium agencies at USD 40 to 80, which is the arithmetic behind the observation that Pakistani rates sit roughly 60 to 80 percent below Western equivalents.

Four things move a database figure more than anything else. Version spread is the one buyers underestimate: four instances on a single version cost far less to hold than two instances three versions apart, because every patch route, every runbook and every restore test then has to exist twice. Coverage hours are the second. Business hours cover and extended cover are different arrangements with different people behind them, and an overnight expectation nobody wrote down becomes an argument at the worst possible moment. Third is whether a standby exists, since a Data Guard pair is a second estate to patch, monitor and prove. Fourth is data volume, which decides how long a restore takes and therefore what anyone can promise the business.

Oracle licences sit outside all of this, and outside us. We do not resell them, entitlement is verified between you and Oracle or your reseller, and nothing we recommend earns us a margin either way. Where database work forms part of a wider programme the published enterprise bands apply instead, with market pricing for multi site scope covering manufacturing and integrations starting at PKR 3,000,000 and rising with the integration count. Every figure above is market context rather than a quotation. Ours follows discovery, once we have read the alert log, the backup catalogue and the privilege list, and it arrives written against a scope both sides have agreed.

  • Version spread and coverage hours priced separately rather than folded into one rate
  • Standby and disaster recovery environments counted as estate, because that is what they are
  • Oracle licences contracted directly with the vendor or your reseller, with no margin to us
  • Assessment quoted as a fixed piece of work, with the written baseline as its deliverable
  • A real figure issued after discovery, against a scope both sides have signed
02

How long a database engagement takes

Assessment is quick. With access agreed in advance, a baseline and a ranked finding list are days of work rather than weeks, and the document exists before anybody has argued about remediation. The time goes afterwards, into the fixing, and how long that takes depends on which findings you accept and which you decide to defer.

Publicly reported delivery timelines in the Pakistani market give a usable frame. A focused single company scope reaches go live in six to twelve weeks. An SME programme runs three to six months. A large enterprise, with several sites and a queue of interfaces behind it, runs nine to twelve months. Database work inside those programmes follows the same clock, because it is gated by the same change windows and frequently by the same three people.

Slowness has recognisable causes. A version gap wide enough to force a stepping stone upgrade turns one outage into three. A packaged application whose vendor certifies only certain versions quietly removes options you had assumed were available. Rehearsal environments that do not yet exist have to be built before anything can be tried, and building one is a small project of its own. Then there is the calendar. A business with no quiet week offers narrow windows, and narrow windows stretch everything downstream of them. We would rather set a date that survives contact with your quarter close than one that reads well in a proposal.

  • Assessment access agreed before the engagement starts, not negotiated during it
  • Stepping stone upgrades identified early where the version gap requires them
  • Application vendor certification checked before a target version is chosen
  • A rehearsal environment available before any change is scheduled
  • Outage windows negotiated with the business owners who feel the outage
03

Oracle, SQL Server and PostgreSQL, managed or in house

Oracle earns its place where the estate is already Oracle and where the features are genuinely used. Real Application Clusters, Data Guard across sites, partitioning at scale and the diagnostic tooling are strong, and a packaged application certified only on Oracle settles the argument by itself. The consideration is that capability and cost are coupled here more tightly than elsewhere, so the design has to be deliberate about what it switches on. Estates that inherited Oracle a decade ago and now use almost none of it are the ones worth reviewing honestly.

SQL Server suits organisations whose gravity is already Microsoft. Directory integration, reporting through the same stack and a hiring market in Karachi and Lahore that is deeper for SQL Server than for Oracle all count for something real. Its commercial model is easier to reason about, which matters when a finance director wants a number they can defend to a board.

PostgreSQL carries no licence fee, and that is where most conversations start and stop, which is a pity because it is not the interesting part. What actually changes is that support becomes something you buy or staff rather than something bundled with the product. For new build it is frequently the right default. Migrating a working Oracle system onto it is an application project rather than a database task: stored procedures, packages, sequences, hints and error handling all behave differently, and the application above usually needs changing too. Budget for the testing rather than only the conversion, because the defects that matter surface in reporting queries and in the edge cases finance notices first.

Managed or in house is a separate question, and the answer is often both. An in house DBA knows why your application does the strange thing it does, which no external party learns quickly. What one person cannot do is cover leave, illness, resignation and four in the morning simultaneously. A managed arrangement supplies cover, runbooks, restore evidence and a defined monthly cost, and its weakness is distance from the application. The shape that works best keeps your own DBA close to the application and places the out of hours cover, the patch route and the recovery evidence with us.

  • Oracle where the features are used, not where the logo is familiar
  • SQL Server where the organisation is already Microsoft centred and hiring is easier
  • PostgreSQL as the default for new build, with support bought or staffed deliberately
  • Migration off Oracle scoped as an application project rather than a database task
  • Managed cover and an in house DBA treated as complements rather than alternatives
04

Licence exposure, restore evidence and data residency

Licence exposure is the quiet risk in an Oracle estate, and it rarely arrives through anybody behaving badly. Metrics drift. A server gains cores during a hardware refresh, a virtualisation change alters what has to be counted, a test environment cloned from production carries an enabled option across with it. The defence is unglamorous: a current written record of what is enabled, on which host, with how many cores, reviewed whenever the infrastructure moves. Interpretation of your agreement is a matter for you, Oracle and your reseller. We are not a licensing auditor and will not present our record as a legal opinion.

Backups deserve a harder test than the one they usually receive. A job reporting success proves that a file was written. What matters is whether a database opens at a chosen point in time, on hardware you actually have, with the application connecting afterwards and the figures reconciling. We run that as a dated exercise and keep the evidence, including how long it took, because the duration is the number the business needs and the one nobody thinks to record.

Privileges accumulate. Shared accounts outlive the person who created them, application accounts hold rights nobody has justified in years, and service credentials sit inside scripts on servers whose owners have changed twice. An audit establishes who holds what and which of it has actually been used, and that second half is what makes withdrawal safe rather than exciting. Leavers deserve a check of their own, run separately from the periodic review.

Residency is not only a question about the primary database. Standby copies, backup destinations, monitoring telemetry and any managed service in the chain each hold data, and each of them sits somewhere. Write down where. Where your sector's regulator has a view, establish it through your own compliance advisers rather than inferring it from a supplier's marketing, and note that billing in rupees and hosting in Pakistan are two different claims.

  • A current record of enabled options, hosts and core counts, reviewed after any refresh
  • Restore tests dated, timed and evidenced, including the application connecting afterwards
  • Privilege lists checked against actual use before anything is withdrawn
  • Leaver checks run separately from the periodic privilege review
  • Every copy of the data located, standby, backups and monitoring included
05

Cloud or on premise

Managed database services remove the mechanics. Patching, backup scheduling and failover are handled for you, and for a small team that is genuine relief. What you give up is version choice, superuser access and part of the tuning surface, which is comfortable until the day an application vendor certifies only a version the service does not offer.

Distance costs more than people expect. An application sitting in a Karachi office and talking to a database in a distant region pays for every round trip, and a chatty application makes thousands of them per screen. Local hosting exists, bills in rupees and removes the exchange rate question from a multi year budget. Test the real application over the real link before committing, rather than a synthetic benchmark on a quiet afternoon.

On premise keeps control and makes cost predictable. It also hands you the discipline. Patching, capacity planning, spare parts and the data centre relationship all become yours to maintain, and organisations that choose it for control and then defer patching for two years end up with the worst of both. Entitlement behaves differently across virtualised and cloud environments as well, so that question belongs before the migration rather than after it.

  • Application latency tested over the real link before a hosting decision is made
  • Version support checked against your application vendor certification list
  • Rupee billing and Pakistani hosting confirmed separately, since they are different things
  • Patching discipline budgeted for where on premise is chosen for control
  • Entitlement in virtualised and cloud environments checked before migration
How we deliver

Delivering Oracle & databases

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

Recovery is the only claim worth making

Strip everything else away and one question remains. If the primary database were lost this afternoon, how long until the business is transacting again, and how much would be gone. Answering that with a document and a tested procedure is the point of the practice. Answering it with an assurance that backups run nightly is how organisations discover, at the worst possible moment, that nobody had ever tried.

Everything else described above serves the same purpose from another direction. A documented baseline means a stranger can act. Staged privilege withdrawal means a compromised account reaches less. Evidence based tuning means an improvement can be shown rather than claimed. None of it depends on heroics, which is fortunate, because heroics are rarely available at four in the morning on a public holiday.

We work across Oracle, SQL Server and PostgreSQL, on assessment, build, managed administration and one off remediation, with RMAN and Data Guard where the platform is Oracle. Where an assessment concludes that your arrangement is sound and the sensible next step is a restore test twice a year, that is what we will write down, even though it is smaller than the work you asked us to quote for.

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

Oracle & databases: the questions we are asked

Typical market rates in Pakistan are set by seniority rather than by product. Published hourly figures put full stack work at PKR 3,500 to 8,000 and senior specialist work at the top of that band. Database administration sits with the specialists. What moves the total is version spread, coverage hours, whether a standby exists, and how much data a restore has to move. We quote after discovery.

An assessment produces a written baseline within days. The remediation afterwards is what consumes time. Reported delivery timelines in Pakistan put a focused single company scope at six to twelve weeks, an SME programme at three to six months and a large enterprise at nine to twelve. A version gap wide enough to force a stepping stone upgrade is the most common reason a date moves.

Sometimes, and it is rarely as simple as the saving suggests. PostgreSQL carries no licence fee, but support becomes something you buy or staff. The migration is an application project: stored procedures, packages, sequences and error handling all behave differently, and the application usually changes alongside the data. For new build PostgreSQL is often the right default. For a working Oracle system, cost the migration before assuming it.

They solve different problems. An in house DBA understands why your application behaves as it does, which nobody external learns quickly. One person cannot cover leave, resignation and the early hours at once. Most arrangements that work well keep your DBA close to the application and place the out of hours cover, the patch route and the restore evidence with a supplier.

Yes, and it is worth being precise about what that means. The primary instance is only one copy. Standby databases, backup destinations, monitoring telemetry and any managed service in the chain each hold data and each have a location. We document every copy and where it sits. Whether your sector requires residency is a question for your compliance advisers rather than for us.

Our work spans Oracle 11g through to 23ai, alongside SQL Server and PostgreSQL. Older versions are common in Pakistani estates, and we would rather help you plan a route off one than decline to look at it. Where an application vendor certifies only certain versions, that list constrains the target, so we check it before proposing any upgrade path.

No. We are not a reseller, so nothing we recommend carries a margin for us in either direction. Licences and support agreements are contracted between you and Oracle or your chosen reseller. What we do is tell you which features a design depends on, flag anything separately licensed before it is enabled, and keep a written record of what is running where.

You should be able to answer that from a document rather than from hope. Two numbers matter: how long until the business is transacting again, and how much data is gone. Both need to come from a dated restore test rather than from a backup job report. Where no test has ever been run, that is exactly where we would start.

Unsure what your database baseline is?

A health check produces a written baseline, a restore test and a prioritised list of what to fix first. It is a sensible first engagement.

Book a consultation See all practices