• Save
Kelly potvin nosurprises_odtug_oow12
Upcoming SlideShare
Loading in...5
×
 

Kelly potvin nosurprises_odtug_oow12

on

  • 476 views

 

Statistics

Views

Total Views
476
Views on SlideShare
476
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Kelly potvin nosurprises_odtug_oow12 Kelly potvin nosurprises_odtug_oow12 Presentation Transcript

  • No Surprises Development andEnvironment ManagementStewart Bryson, Rittman Mead& Kellyn Pot’Vin, Enkitec
  • About This SessionOther programming disciplines have taken advantage ofcollaborative development principles to achieve qualitycode faster, such as: Agile methods rapid feedbackWhat techniques are available to enable higher levels ofvisibility and traceability when developing database codeand schema objects.
  • Deployment Strategies in the Workplace Formal Strategy? Agile? Waterfall? Other?
  • Database World View DBAThe GULF In between Developer
  • Challenges The ability to constantly build and deploy code into identical environments is one of the core essentials to ensuring successful releases. There is incredible value in constant environmental comparisons which can reduce potential deployment problems between:  Developer Database Copies  Central Development Databases  Integration Environments  Reporting Environments  Production
  • Secondary Objectives Know more about Oracles built-in capabilities for tracking database changes. Learn how different tools can can support Oracle deployments to facilitate development, deployment, and quality peer reviews. Learn about how to leverage compare tools to reduce potential code movement and deployment issues.
  • Performing a Release, Can you answer:1. Exactly what is being changed in the database?2. If theyre using scripts to make the changes, have thescripts been run against a copy of the production schemaanywhere before attempting them in production?3. How long will the scripts take to run?4. Are all of the scripts documented?5. Is there a run-book /install guide that lists each script?
  • So Much Can Change….5. Which scripts can be "pre-deployed" or "dark-launched"?(i.e. wont affect a running system.)6. Which scripts require an outage?7. Which scripts can be run post-outage?8. If we need to abort, what is the minimum set of things weneed to revert back to pre-deployment versions?
  • What do We Need to Be Successful? What do we want? What do we need?
  • To Ensure You are able to AnswerThese Question, it will Require: Following Environments:  2 in Development  2 in Integration  2 in QA  1 in Production Reporting  1 in Production
  • 1. They dont have a production copy.a) Skills/Resource to Create a Production Copyb) Lack Disk Space to Create Production Copyc) Inability/Lack Resources to Utilize Snap Mirrors/Re-Silveringd) Logical Data Guarde) Golden gatef) Delphix
  • 2. Restrictive security prevents comparing schemas across EnvironmentsRe s tric ts c o m p a ris o ns be twe e n d e v e lo p m e nt, te s t,QAa nd p ro d uc tio n. .a) Ask why, demand a logical answer.b) Find a way around it, there are tools to extract baselinesc) Write a sql script to dump details to a .txt file and just diff themd) Find a process to constantly verify that the structure in Productionis what you expect it to be.
  • 3. They dont practice deployments inthe environments they havea) From Development to Integration or from schema toschemab) From Integration to QA Does QA file bugs when the installation scripts fail?c) From QA to Production Reporting
  • 4. They think that small structuraldifferences "dont matter"a) The index names are different, how could this impact arelease?b) The columns are in a different order, what is the big deal?c) Storage clauses are assumed, it’s an issue?d) They run RAC and DG in production, but nowhere else,it matters?
  • Internal Database Tips DDL Auditing turned on, considered default in environments. It is FREE, has almost no overhead and grants the administrator a list of structural changes occurring as the changes happen. All change scripts should be generated at the object level, (SQL Developer is already equipped to handle this.) Take advantage of schema compare tools repeatedly to “weed out” and eliminate any structural differences prior to deployments. Test, test and re-test deployment scripts, preference is always against a production copy.
  • Tips for Simplifying Environments Tablespace names the same across ALL environments. Storage clauses all AUTO ALLOCATE Column ordering the same. Index checks to verify all the same across all environments. Remove ALL DIFFERENCES that can impact simplicity when duplicating. Consider differences to be bugs that require fixing. If production is RAC, all environments that support it, (dev, test, QA) should also be RAC!
  • Cost Effectiveness Price of implementation vs. the cost of failure. Track accumulated savings in shortened outage windows. Consider more frequent deployments, which can be performed quickly and confidently.
  • Tools that Can Assist You SQL Developer, (Oracle) Pl/SQL Developer, (All Around Automation) TOAD Software, (Quest Software) Redgate Deployment Suite for Oracle DB Artisan, (Embarcadaro)  Object Level Scripting  Schema Comparison  Plug-in for many version control software pkgs.
  • Oracle Deployment Tools Oracle Technology Network Website has documentation for a plug-in.http://www.oracle.com/technology/documentation/agile.html Weblogic applications possess the Weblogic Deployment tool. Oracle Warehouse Builder EM12c-  Use Middleware as a service as to rapidly deploy J2EE applications.  Auto deploy options for patching, upgrading, etc of Oracle internal code.
  • Production Deployments Best PracticeReview A practiced task before the actual event, at least 2-3 occurrences before going production. All issues/bugs should be ironed out before ever going to production so… The Production Deployment is then a NON- EVENT!