D0 Taking Stock

1
D0 Taking Stock

• By Anil Kumar
• CD/LSCS/DBI/DBA
• June 11, 2007

2
Outline

• Infrastructure
• Space Usage
• Capacity Planning
• Backup Recovery
• SAM Schema
• Accomplishments
• Whats Next
• Concerns
• Q A

3
D0 offline Production/Integration Infrastructure

• 8 900MHz CPU 32G RAM
• The machine has a Clariion 4500 hardware raid
  array
• Oracle Server 10gR2 (64 bit) on Solaris 2.9 (64
  bit)
• Load Avg. 4-6 CPU usage 53 , Memory Free
  50 ( 16GB)
• Uptime excluding scheduled down times 100
  Uptime since June, 2006 vs 99.97716 last year.

4
D0 offline production Luminosity

• Sun v40z with 2 AMD 844MHz CPU, RHEL3 x86_64, 16G
  RAM
• 2 Ultra 160 RAID controllers
• Oracle server 10gR2
• Load Avg. 1 CPU usage 3-60 , Memory Free
  20M
• Uptime excluding scheduled down times 100
  since June 2006

5
D0 offline development Infrastructure

• D0ora1
• Sun E4500
• 8 400 MHz CPU, 4GB of RAM
• Oracle 10gR2 64 bit on Solaris 2.9
• Load Avg 1-2 , CPU usage 33, Memory Free 19
• D0lum1
• Sun v40z with 2 844MHz AMD CPU
• RHEL3 x86_64
• 16G RAM
• Oracle server 10gR2
• Load Avg 1, CPU usage 4, Memory Free 74M

6
Space Usage
7
Space Usage Summary

• d0ofprd1 257 GB used.
• d0ofint1 185 GB used.
• 2TB available for int and production.
• d0ofdev1 107 GB Used
• 165GB is available for use.
• d0oflumd 298GB used
• doflumi 495MB used
• 170GB is available for d0oflumd and
  d0oflumi
• D0oflump 627GB used
• 1 TB is available.

8
Capacity Planning

• Next three years expected growth 300Gb
• SAM growth 80Gb/year and other apps
  10Gb/year (this exclude Luminosity DB )
• We have around 2TB available.
• Next three years Luminosity growth is 500Gb.
  There is 1TB available.

9
Back-up/Recovery

• D0ofprd1
• Daily, 4 days of archives.
• Allocated 4TB, Used 1.2TB (2 copies), RMAN
  Back-up time -gt 2 Hrs No Export. Both copies of
  rman backup to SAN. No local copy.
• Backups taken to dcache 3x/week
• D0lump
• Daily, 4 days of archives
• Allocated 3TB, Used 2.2 ( 2 copies), RMAN
  Back-up time -gt 6 Hrs No Export. Both rman backup
  copies are on SAN. No local copy.
• Backup to dcache daily.

10
SAM Schema

• Production Deployments
• Retiring Files v6_3
• Indexes v6_4, v6_5,v6_6, v6_8 , v6_9
• Sequence Cache V6_7
• Work-in-progress
• - v6_10 Global temporary tables.
• Upgrade to Mini SAM as SAM Schema Evolved. -gt
  This facilitate individual developers to have
  copy of SAM metadata and seed data available for
  server software rewrite if needed.
• Discontinued supporting the postgres version of
  SAM schema as per last year taking stock meeting.
  

11
Accomplishments

• Quarterly Database Security/OS patches
  Up-to-date.
• Upgraded the d0 offline Lumi databases to 10gR2.
• Upgraded the designer repository to 10gR2
• Disk capacity upgrade for d0 offline lum db
  production db.
• OS upgrade on d0online Db
• Disk capacity Upgrade for d0online db machines.
• Merged the monitoring of d0 online with central
  monitoring for all dbs.
• Migrated the d0 online designer users to central
  designer repository.
• Took over the System Support for d0 online db
  machines.

12
Accomplishments

• Depreciated the events on d0offline db. Recovered
  space 800GB
• Deployment SAM v6_0 through v6_8. This includes
  the SAM request system.
• Began Testing and deployment of 3PAR SAN storage
  to replace clariion array.
• Bundled the Redhat licenses into one P.O.
• Deployed additional weekly schema analysis for
  SAM for tuning

13
Whats Next ?

• Replacement of Aging Clariion Array with 3par SAN
  storage including int/prd d0 offline database
  instances to 3par array.
• Take Over support for d0 online databases by end
  of June 2007
• Upgrade the Oracle databases to version 10.2.0.3
• ASO ( Advanced Security Option) Deployment

14
Concerns

• Python Dcoracle to be built with Oracle 10g
  client. Oracle recommends client version should
  be same as Database Version.
• Any Oracle Patch may break Pyhton Dcoracle
  built with 8i client.
• Single point of failure with D0 offline database.
  
• Hardware for D0 DB server machines is very old.
  Should consider upgrading the hardware for d0 db
  servers.
• Speaker Bureau schema in development db being
  used in production mode. This schema must be
  moved to production.
• Not enough disk capacity on d0ofline lum dev/int
  machines to do production refresh.
• Note Investigating hardware configuration
  if 3par array can be attached to d0lum1.
• This will facilitate the full
  integration refresh from production.

15
Q A

• Q A