SmartLink
Data platform

Oracle database build and design in Pakistan: sizing, cost and standards

Oracle database build and design work in Pakistan is usually commissioned late, once an application project has already chosen its framework and fixed its go live date. SmartLink Services runs this work from Karachi, on Oracle, PostgreSQL and SQL Server, sized against a real workload rather than a licence bracket, with the standards written while the decisions are being taken instead of afterwards. This page covers what a build costs at published market rates, how long a production ready instance takes once sizing inputs arrive, and the design question that governs the next five years: whether the schema is designed deliberately or left to the application framework to generate. We do not supply servers or storage.

Discuss this service
Deliverable
Production-ready instance
HA options
RAC \u00b7 Data Guard
Standards
Written and enforced
Overview

Decide high availability before the first outage decides for you.

A new database is one of the few chances to make decisions cheaply. Storage layout, character set, schema separation, partitioning strategy, naming standards and the high availability position are all straightforward before there is data in the system, and all expensive afterwards. Most of the databases we are later asked to tune or rescue were built quickly, correctly for the day, and never revisited once the workload changed shape underneath them. None of that is negligence. It is simply what happens when a build leaves no document behind it.

Sizing comes first, and it comes from workload rather than from a licence bracket. Expected transaction volumes, the concurrency profile, the ratio of reads to writes, the batch windows that have to be met, retention requirements and growth across the intended life of the system. Those numbers are estimates and we treat them as estimates, which means the design accommodates being wrong by a reasonable margin instead of assuming the figure is a fact. Where a number is a guess, we record it as a guess and note what would change if it turns out to be wrong.

The build is then produced as a repeatable runbook rather than a set of actions performed once by somebody who was there. Anyone should be able to rebuild the environment from the document, which is what makes a test environment genuinely resemble production and what makes disaster recovery credible. Standards, operating procedures and the handover pack are written during the build, not promised for some point afterwards. Documentation deferred to the end of a project is documentation written by somebody with a deadline, and it reads that way. Writing it as decisions are taken costs less.

Scope

What Oracle database building 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

  • Workload sizing and storage layout planning
  • Schema, partitioning and indexing strategy
  • Naming, coding and change standards
  • High availability and standby configuration
  • Backup strategy defined against agreed RPO and RTO
  • Security baseline applied at build time

What you get at handover

  • Architecture and sizing document
  • Build runbook, repeatable
  • Schema and partitioning specification
  • HA and failover test results
  • Operations handover pack

Typically involves

ASM
Discuss this service
01

Sizing against a workload rather than a licence bracket

Hardware decisions are often made from a price list and then justified with a workload description written to fit the answer. That gets things approximately right for the first year and creates a ceiling nobody sees coming. Sizing properly starts with the transactions the system will actually process, the hours of the day when they cluster, and the batch work that has to complete inside a window somebody else depends on. Growth across the intended life of the system belongs in the same calculation.

Storage is where mistakes are least reversible. Layout across disk groups, redo placement, archive log destination sized against real archive generation rather than a guess, temporary space for the largest sort the reporting workload will produce, and headroom for growth that is already known about. Character set belongs in the same conversation, since changing it later on a populated database is a migration project rather than a configuration change. The same applies to block size and to several storage decisions that look adjustable and are not.

Licensing deserves an honest discussion early. Some features are attractive, easy to enable and separately licensed, and it is common to find a database quietly using something nobody bought. We identify what the design genuinely needs, what would merely be pleasant to have, and what each option costs, so that the choice is made deliberately by somebody who can approve it rather than defaulted by an installer screen. Discovering an unlicensed feature during an audit is an expensive way to learn what was enabled by default.

  • Sizing derived from transaction volume, concurrency, batch windows and retention requirements
  • Storage layout, redo placement and archive destination sized against real archive generation
  • Temporary and undo space sized for the largest expected sort and the longest running query
  • Character set and core configuration decided before load, since changing later is a migration
  • Licensed features identified explicitly, so nothing is in use that has not been purchased
02

Choosing between a standby and a cluster honestly

RAC and Data Guard solve different problems and are regularly confused in requirement documents. A cluster protects against the loss of a node and allows scaling across instances. A standby protects against the loss of a database, a datafile or an entire site. An organisation that needs protection from site loss and buys a cluster housed in a single room has purchased availability for the wrong failure and will find out at the worst time.

The design starts from two numbers agreed with the business: how much data you can afford to lose, and how long you can afford to be unavailable. Those drive whether the standby is synchronous or asynchronous, whether it sits in the same building or somewhere else entirely, and whether the operational complexity of a cluster is justified. Both answers cost money, so they belong to the business rather than to the technical team. Our job is to price the options honestly and explain what each one buys.

Whatever gets built has to be exercised. A standby that has never been opened for a switchover is a hypothesis with a licence attached. We test failover and failback during the build itself, with the application team present, and record how long each took and what had to change on the application side. That test then becomes part of the operating schedule rather than a commissioning activity nobody repeats. Application behaviour during a failover is the part that surprises people, and it changes every time the application does.

  • Recovery point and recovery time objectives agreed with the business before the design is fixed
  • Standby placement chosen against the failure being protected against, including loss of a site
  • Cluster complexity justified by a stated requirement rather than adopted as a default
  • Switchover and failback tested during the build, with application behaviour observed and recorded
  • Failover testing scheduled as routine work, not left behind as a commissioning exercise
01

What an Oracle database build costs in Pakistan

No published market band exists in Pakistan for a database build on its own, and anybody quoting one is quoting themselves. What can be stated is the shape. The closest published project band is custom application development at PKR 200,000 to 1,000,000 and up, and a database build is usually either priced inside that or quoted against hours. Market hourly rates here run PKR 3,500 to 8,000 for full stack work, with senior specialist time at the top of that range and junior work at PKR 500 to 1,000. An Oracle database build is senior work, because the expensive mistakes are all made in the first fortnight.

Environment count is the first driver and the one most often left out of a comparison. Development, test and production each need building, patching, refreshing and space, and a training environment or a separate performance environment is a further instance with a further invoice behind it. High availability is the second. A standby is not a setting, it is a second estate to build, monitor, patch and prove, and a cluster is more again. The third is data. A build seeded from an existing system carries an extraction, a mapping and a reconciliation, and that work is sized after the source has been profiled rather than before.

Two smaller items move numbers more than their size suggests. Documentation depth is one: a runbook anybody can rebuild the environment from takes real hours to write and is the difference between a test environment that resembles production and one that merely claims to. Security applied at build time is the other, and it is far cheaper here than retrofitted later, which is the whole argument for doing it now. Licences are contracted with the vendor and carry no margin to us. Treat everything above as market context. A real figure follows discovery, once the environment list, the availability position and the source data are agreed.

  • Every environment counted and costed, including the training and performance instances
  • High availability priced as a second estate rather than as a configuration setting
  • Seeding data from an existing system sized after the source has been profiled
  • The build runbook written as the build happens, so the environment can be rebuilt by anyone
  • Security baseline applied at build time, where it costs a fraction of the retrofit
02

How long a database build takes

The technical part of an Oracle database build is short. Installing, configuring, laying out storage and creating schemas on agreed standards is a matter of days for a single instance, and the honest answer to how long it takes is therefore a question about everything around it. Reported delivery timelines in Pakistan put a focused single company scope at six to twelve weeks and an SME programme at three to six months, and a database build sits inside one of those rather than beside it.

Sizing inputs are the usual delay. Somebody has to supply expected transaction volumes, the concurrency profile, the read to write ratio, the batch windows that must be met and retention requirements, and in most projects nobody owns those numbers. We would rather record an estimate as an estimate, with a note of what changes if it turns out wrong, than wait a month for a figure that will be a guess anyway.

Three things stretch a build here. Infrastructure procurement runs on somebody else's calendar, and a server that arrives in week seven decides the plan whatever the software team does. A standby in a second building waits on a link being provisioned, which is a telecommunications order rather than a technical task. Failover testing needs the application team present, because a switchover nobody watched from the application side proves less than it appears to. We schedule the failover test as a named event with named attendees rather than as a line on a checklist, and where the application team cannot attend, the test moves rather than proceeding without them.

  • Sizing inputs requested early and recorded as estimates where that is what they are
  • Infrastructure procurement tracked as a dependency with its own owner and date
  • Standby links treated as a telecommunications order placed well ahead of the build
  • Failover proved as an attended test with the application team watching their own side
  • Standards, runbook and handover pack written during the build rather than promised after it
03

Designing the schema or letting the application create it

Most new databases in Pakistan are now created by an application framework. The developer defines classes, the tool generates tables, and a working schema exists within an afternoon. That is a genuine advantage and we would rather argue about it honestly than pretend otherwise. It is fast, it stays in step with the code, and for a system whose data will never grow past a few million rows it is frequently the right answer for the whole life of the product.

What the generated schema does not do is plan for the years after launch. Framework conventions produce surrogate keys everywhere, columns left nullable because the class allowed it, indexes created per relationship rather than per query, and no partitioning at all, because no framework knows how you intend to purge. None of that hurts in month one. It hurts in year three, when a reporting query scans a table of several hundred million rows with no partition key, and the only remedies left require an outage the business will not grant.

The split we usually recommend leaves the transactional tables to the framework and designs the parts that outlive the application. Keys that mean something to the business, so a record can still be identified after the application is replaced. Audit columns with a stated meaning rather than three variations on when a row changed. A partition key chosen for how data will be archived and purged, decided before the first load. Referential integrity enforced in the database as well as in the code, because the second application to connect will not know the rules the first one held in memory. A naming standard that survives the third developer.

Cost settles this more often than principle does, and the arithmetic is rarely spelled out. Designing this deliberately adds days to a build. Correcting it later is an outage, a data migration and a regression test on a live system, and it is usually declined on those grounds and lived with instead. We write the design down, we say which parts we would leave to the framework, and we do not rewrite your application to suit the database.

  • Framework generated tables accepted where the data volume genuinely stays small
  • Business meaningful keys designed deliberately, so records survive the application that created them
  • Partition and archive strategy decided before the first production load
  • Referential integrity enforced in the database, since the second application will not know the rules
  • A naming and change standard written down at build time and enforced afterwards
How we deliver

Delivering Oracle database building

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

We will argue against over engineering

Not every database needs a cluster, a synchronous standby in a second site and a partitioning strategy on every table. Complexity has an ongoing cost in operations, in testing, and in the number of people who understand the environment well enough to fix it under pressure at midnight. Where a well configured single instance with a tested standby and a proven restore procedure meets the requirement, that is what we will recommend, even though a larger design is easier to sell.

The commitment that goes with it is that the simpler design is genuinely finished. Standards written, backups configured and proven by restore, security baseline applied at build time rather than retrofitted later, monitoring in place with a runbook, and a handover pack that lets somebody else operate the environment. A modest architecture built properly outlasts an ambitious one that nobody ever documented.

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 Oracle database building

There is no published band for a database build alone. The nearest published market figure is custom application development at PKR 200,000 to 1,000,000 and up, and most build work is quoted against hourly rates of PKR 3,500 to 8,000 for senior technical time. Environment count, the high availability position and any data seeded from an existing system move the number most. We quote after discovery.

The technical build of a single instance is days. What sets the date is everything around it. Reported timelines in Pakistan put a focused scope at six to twelve weeks. Infrastructure procurement, a standby link that has to be provisioned and an attended failover test are the three items that most often move a build date, and none of them is shortened by adding people.

Often, yes, and for a system that stays small it is the sensible answer. What a generated schema will not give you is a partition key, business meaningful identifiers or constraints enforced below the application. Those matter once volume grows or a second system connects. Our usual recommendation is to let the framework own the transactional tables and to design the parts that outlive it.

Size for the horizon you can defend and design so that being wrong is survivable. Five year figures in a new business are guesses, and building for a guess is how estates end up expensive and empty. We record which numbers are estimates, note what would change if they are wrong, and choose a storage and partitioning layout that can grow without a rebuild.

That is the normal case, so the design assumes it. Storage layout, partitioning and the archive boundary are the three decisions that make growth cheap or expensive, and they are settled at build time. Where the gap is very large the honest answer may be a change of platform or of hosting, and we would rather say that early than tune around it for a year.

Yes, on either, and the design work is much the same. What changes is who holds superuser access, which versions are on offer and how a restore is proved. Check your application vendor certification list before choosing a managed service, because a version that is not on the menu is a constraint you cannot negotiate later. We do not supply servers or storage in either case.

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

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 close bottlenecks diagnosed with evidence, not guesses.

Open service page → Data platform

Data warehouse & BI

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

Open service page →

Building a new database estate?

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

Book a consultation All oracle & databases