Troubleshooting

OpenWorks Troubleshooting Guide
2004 Landmark Graphics Corporation
Part No. 161622 R2003.12.0.1
March 2004
2004 Landmark Graphics Corporation All Rights Reserved Worldwide This publication has been provided pursuant to an agreement containing restrictions on its use. The publication is also protected by Federal copyright law. No part of this publication may be copied or distributed, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, magnetic, manual, or otherwise, or disclosed to third parties without the express written permission of: Landmark Graphics Corporation Building 1, Suite 200, 2101 CityWest, Houston, Texas 77042, USA P.O. Box 42806, Houston, Texas 77242, USA Phone: 713-839-2000 Fax: 713-839-2401 Web: www.lgc.com Trademark Notice 3D Drill View, 3D Drill View KM, 3Dview, Active Field Surveillance, Active Reservoir Surveillance, ADC, ARIES, Asset Development Center, Asset Development Centre, Automate, BLITZ, BLITZPAK, CasingSeat, CDDM, COMPASS, Corporate Data Archiver, Corporate Data Store, DataStar, DBPlot, Decision Suite, Decisionarium, DecisionDesktop, DecisionSpace, DecisionSpace AssetPlanner, DecisionSpace AssetView, DecisionSpace Atomic Meshing, DecisionSpace Power Grid, DecisionSpace PowerModel, DecisionSpace PrecisionTarget, DecisionSpace TracPlanner, DecisionSpace Well Seismic Fusion, DepthTeam, DepthTeam Explorer, DepthTeam Express, DepthTeam Express3, DepthTeam Extreme, DepthTeam Interpreter, DESKTOP-PVT, DESKTOP-VIP, DEX, DFW, DIMS, Discovery, Drill-to-the-Earth Model, Drillability Suite, DrillModel, DrillVision, DSS, Dynamic Reservoir Management, Dynamic Surveillance System, EarthCube, EDM, eLandmark, Engineers Data Model, Engineer's Desktop, EOS-PAK, EPM, Executive Assistant, ezFault, ezSurface, ezTracker, FastTrack, FZAP!, GeoDataLoad, GeoGraphix (stylized), GeoGraphix Exploration System, GeoLink, GeoProbe, GES, GESXplorer, GMAplus, GRIDGENR, Handheld Field Operator, I2 Enterprise, iDIMS, IsoMap, Landmark, Landmark and Design, Landmark logo and Design, LandScape, Lattix, LeaseMap, LMK Resources, LogEdit, LogM, LogPrep, Magic Earth, MagicDesk, MagicStation, MagicVision, Make Great Decisions, MathPack, MIRA, Model Builder, MultiWell, MyLandmark, MyWorkspace, OpenBooks, OpenExplorer, OpenJournal, OpenOrigin, OpenSGM, OpenVision, OpenWells, OpenWire, OpenWorks, OpenWorks Well File, PAL, Parallel-VIP, PetroBank, PetroWorks, PlotView, Point Gridding Plus, Pointing Dispatcher, PostStack, PostStack ESP, PowerCalculator, PowerExplorer, PowerJournal, PowerModel, PowerSection, PowerView, PRIZM, PROFILE, ProMAGIC, ProMAX, ProMAX 2D, ProMAX 3D, ProMAX 3DPSDM, ProMAX MVA, ProMAX VSP, pSTAx, QUICKDIF, QUIKCDP, QUIKDIG, QUIKRAY, QUIKSHOT, QUIKVSP, RAVE, RAYMAP, Real Freedom, Real-Time Asset Management Center, Real-Time Asset Management Centre, Real Time Knowledge Company, RESev, ResMap, RMS, SafeStart, SCAN, SeisCube, SeisMap, SeisModel, SeisSpace, SeisVision, SeisWell, SeisWorks, SeisWorks MultiView, SeisWorks PowerCalculator, SeisWorks PowerSection, SeisWorks PowerView, SeisXchange, Sierra, Sierra (design), SigmaView, SimResults, SIVA, Spatializer, SpecDecomp, StrataAmp, StrataMap, Stratamodel, StrataSim, StratWorks, StressCheck, STRUCT, Surf & Connect, SynTool, SystemStart, SystemStart for Clients, System Start for Servers, SystemStart for Storage, T2B, TDQ, Team Workspace, TeamView, TERAS, Total Drilling Performance, TOW/cs The Oilfield Workstation, Trend Form Gridding, Turbo Synthetics, VIP, VIP-COMP, VIP-CORE, VIP-DUAL, VIP-ENCORE, VIPEXECUTIVE, VIP-Local Grid Refinement, VIP-THERM, WavX, Web Editor, Web OpenWorks, Wellbase, Wellbore Planner, Wellbore Planner Connect, WELLCAT, WELLPLAN, WellXchange, WOW, Xsection, Xsource, Youre in Control. Experience the difference, ZAP!, and Z-MAP Plus are trademarks, registered trademarks, or service marks of Landmark Graphics Corporation or Magic Earth, Inc. All other trademarks are the property of their respective owners. Note The information contained in this document is subject to change without notice and should not be construed as a commitment by Landmark Graphics Corporation. Landmark Graphics Corporation assumes no responsibility for any error that may appear in this manual. Some states or jurisdictions do not allow disclaimer of expressed or implied warranties in certain transactions; therefore, this statement may not apply to you.
Landmark
Contents
Overview
Whats in this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Basic Troubleshooting
Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Symptoms of Trouble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Troubleshooting Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Checking Essential System Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Checking Which Processes Are Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Starting Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Killing Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Try This First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Killing a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Telneting from Another System and Using the Kill Command . . . . . . . . . . . . . . . . . . . . 9 Killing and Restarting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 On a Solaris System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 On an IBM System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 On a Silicon Graphics System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Checking Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Last Resort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shutting Down the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aborting and Rebooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On a Sun system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 13 13
On an IBM system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 On a Silicon Graphics system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Where to Look for More Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Other Useful Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
R2003.12.0.1 Contents iii
Landmark
Tools for Troubleshooting

Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Environment Status Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Checking the OpenWorks Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Project Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Using LGC_DEBUG for SeisWorks Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activating/Deactivating LGC_DEBUG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In a Bourne Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In a C Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using LGC_DEBUG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 22 22 23 23
Troubleshooting Data-Related Problems

Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Data Troubleshooting Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks Users: Do You Have an OpenWorks Project? . . . . . . . . . . . . . . . . . . . . . . . All Users: Is Your OpenWorks Environment Properly Configured? . . . . . . . . . . . . . . . All Users: Can You Access Oracle? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 27 29
Oracle Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Troubleshooting Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Access Problems in OpenWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment Variables Are Not Set Properly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OWSYS Does Not Exist or Cannot Be Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OWSYS May Not Have Been Properly Created . . . . . . . . . . . . . . . . . . . . . . . . . . . A Project Database Exists in Oracle, But Is Unknown to OpenWorks . . . . . . . . . . The Data Access System Cannot Find the Data Files . . . . . . . . . . . . . . . . . . . . . . . A Data Access Failure Occurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Depth Preference Is Not Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Priority List is Not Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . You Are Not the Owner of a Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ancillary Messages That Can Be Ignored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv Contents
36 36 36 36 37 37 38 39 39 39 40 40
R2003.12.0.1
Landmark
A Project Fails to Delete Completely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Access Problems in SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Your Project Does Not Appear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problems with 2DPlus Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problems with 3DPlus Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Permission Mode of a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examining the Currently Assigned Permissions . . . . . . . . . . . . . . . . . . . . . . . . Customizing Permissions for Different User Types . . . . . . . . . . . . . . . . . . . . . . Granting Read, Write, and Execute Permissions to All User Types . . . . . . . . . . Problems with Horizons in SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Make Another Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Horizon List Incorrect or Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks/2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks/3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Horizons in Map View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problems with Faults in SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correlating Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Plane Not Listed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Assign Fault Heave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying Faults in Map View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suspect-Looking Fault Contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41 43 43 43 44 44 44 46 47 47 47 48 48 48 49 49 49 49 50 50 51
Problems Exporting Data from SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Checking the Continuity of SeisWorks/2D Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Data Loading Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Data Loading Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TVD Total Depth for Deviated Wells is Too Shallow . . . . . . . . . . . . . . . . . . . . . . . Message: Records dropped due to errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wells Appear in 2D Display but not in Map View (SeisWorks) . . . . . . . . . . . . . . . Well Symbols Appear in 2D Display but not in Map View . . . . . . . . . . . . . . . . . . . Wells Appear in Map View but not in Seismic View . . . . . . . . . . . . . . . . . . . . . . . . Wells Appear in Seismic View, but not Curves or Tops . . . . . . . . . . . . . . . . . . . . . Geologists Tops not Appearing Correctly in Seismic View . . . . . . . . . . . . . . . . . .
R2003.12.0.1 Contents
54 54 54 54 54 54 55 55 55 55
v
Landmark
Synthetics do not appear in Seismic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Troubleshooting Seismic Display Problems

Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Problems with Seismic Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No Seismic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks/2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks/3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Snow or Stripes on Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gaps or White Spots on Seismic Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problems with Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cant Get Dual Color Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No Data Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No Color Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partial Data Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 58 58 58 58 58 59 59 59 59 59
Other Display Problems in SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Troubleshooting Computed Contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Troubleshooting Your Well Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Troubleshooting System Problems

Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Checking OpenWorks System Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting/Stopping System Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting/Stopping the Pointing Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the LAM Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping the LAM Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processes Initiated on Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifications to System Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 64 65 65 66 66 66 67
Troubleshooting System Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vi Contents R2003.12.0.1
Landmark
Troubleshooting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solaris Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sun, Silicon Graphics, and IBM Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problems Starting SeisWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /tmp Directory Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sys Directory Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68 68 68 68 68 69
Troubleshooting Oracle Problems

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Before Using These Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Documenting and Reading Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 OpenWorks Requirements for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Recommended Datafile Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Items Affecting Size Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 System Tablespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Rollback Tablespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Database Block Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Oracle Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Applying the Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 The Environment Status Tool and Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot open the database instance configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . Could not find Oracle Project Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Could not find the Oracle Database Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 77 78 78
Using Server Manager to Query the Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Oracle in a Networked Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 The listener.ora file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 The tnsnames.ora file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Troubleshooting Oracle Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Database Processes May Not Be Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
R2003.12.0.1 Contents vii
Landmark
Unable to Connect to a Local Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unable to Connect to a Remote Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unable to Halt the Oracle Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Shut Down Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot Start Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Files Moved or Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object or Data Lost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Resource Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Connection Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86 86 87 87 87 88 88 89 89 90
Common Error Messages

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Whats in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Setting the Error Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking the Error Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Error Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In a Bourne Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In a C Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . For Applications Started from the Command Menu . . . . . . . . . . . . . . . . . . . . . . . . For Applications Started from an xterm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directing Error Messages to a script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directing Error Messages to a Text File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 94 95 95 95 96 96 97 97 98
Using the OpenWorks Error Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Common OpenWorks Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The master database owsys could not be connected . . . . . . . . . . . . . . . . . . . . . . . . . Error reading the OpenWorks system database (owsys)! . . . . . . . . . . . . . . . . . . . . . Unable to connect to the default $ORACLE_SID database . . . . . . . . . . . . . . . . . . . Cannot open the database instance configuration file . . . . . . . . . . . . . . . . . . . . . . . . OpenWorks Database Project *nowell* Initialized . . . . . . . . . . . . . . . . . . . . . . . . . OpenWorks Database Project <Project_Name>: Access Failed . . . . . . . . . . . . . . You must be the Project Owner to Use this. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii Contents
100 100 100 101 101 102 103 103
R2003.12.0.1
Landmark
Common SeisWorks Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cannot open .sm files. Cannot continue. (SeisWorks/2D) . . . . . . . . . . . . . . . . . . . . Cannot set project or Cannot open project definition file . . . . . . . . . . . . . . . . . . . SeisWorks/2D Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SeisWorks/3D Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error in survey parameters in .pdf and .hrz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No fault segment/heave selected for assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . .pd2 file not present (SeisWorks/2D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewport Not Allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Graphics Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103 103 104 104 104 104 105 105 105 106 106
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
R2003.12.0.1
Contents
ix
Landmark
Contents
R2003.12.0.1
Landmark
Overview
This manual provides troubleshooting techniques you can apply if you encounter problems while using OpenWorks and other Landmark products. In addition to reading the information in this manual, you can call your Landmark customer service representative for assistance.
Whats in this Manual

This manual contains the following chapters: Basic Troubleshooting on page 3. This chapter contains some simple techniques you can use to correct problems. Refer to this chapter at the first sign of trouble. If the solutions described here do not solve your problem, refer to one or more of the more detailed chapters in the rest of the manual. Tools for Troubleshooting on page 17. This section describes the OpenWorks utilities you can use to verify that system processes are running. These tools can help you pinpoint the causes of problems. Troubleshooting Data-Related Problems on page 25. This chapter provides solutions to some problems you might encounter accessing projects or data, as well as problems with importing or exporting data. Troubleshooting Seismic Display Problems on page 57. This chapter can help you with seismic display problems, color bar problems, and problems displaying computed contours and well data. Troubleshooting System Problems on page 63. This chapter describes the system processes used by Landmark applications and provides tips for solving various problems with OpenWorks and SeisWorks.
R2003.12.0.1
Overview: Whats in this Manual
Landmark
Troubleshooting Oracle Problems on page 71. This chapter provides detailed steps you can take to correct problems with your Oracle database. Common Error Messages on page 93. This chapter contains the procedure for setting your systems error level, which determines the types of error message that will appear. This chapter also describes typical system error messages.
Overview: Whats in this Manual
R2003.12.0.1
Landmark
Basic Troubleshooting
This chapter explains troubleshooting techniques you can use if you encounter problems while using OpenWorks or another Landmark product. In addition to reading the information in this chapter, you can call your Landmark customer service representative.
Whats in this Chapter

This chapter contains the following sections: Symptoms of Trouble on page 4. This section lists several specific symptoms of trouble that may occur and suggests a procedure for what to do if one of these problems occurs. Checking Essential System Processes on page 5. This section explains how to check which Unix system processes are running, how to restart a stopped process, and how to kill (stop) a process when the process cannot be stopped by normal means. This section also describes important system processes and files that you may check when troubleshooting. Checking Disk Space on page 11. This section explains how to determine the amount of disk space is available on your system. Last Resort on page 12. This section tells you how to reboot your system, which you should only do if the steps described in the preceding steps have failed to resolve your problem. Where to Look for More Help on page 14. This section describes the remaining chapters of this manual, which contain more detailed troubleshooting procedures.
R2003.12.0.1
Basic Troubleshooting: Whats in this Chapter
Landmark
Symptoms of Trouble
General symptoms of trouble can include any of the following: All processes stop working (system lockup) The mouse cursor does not move An existing window disappears Additional windows cannot be opened Individual applications do not respond to user selections Command Menu does not respond to user selections Command Menu (launcher process) is lost The window title bars are lost (mwm process) Inter-task communications cannot be performed (pd process)
Methods for dealing with each of these problems are explained on the following pages. Many problems can be remedied quickly using non-diagnostic strategies. Often you can resolve problems by exiting the application you are using and then reopening the program. Try this approach if the windows are not opening properly, data appears to be inaccurate, faults are posted in the wrong place, horizons are not properly posted, etc.
Troubleshooting Steps
If closing and reopening the application does not work, or if you are unable to close the application, try one or more of the following: If an application you are using becomes unresponsive, you might need to kill it. See Killing Processes on page 8. Expand your Command Menu to show the status of vital processes. Start any processes that are not running. See Checking Essential System Processes on page 5. Exit OpenWorks using the Exit command from the OpenWorks command menu, and restart OpenWorks.
Restarting OpenWorks restarts all individual tasks. If restarting OpenWorks fails to correct the problem, you can attempt to further diagnose the problem by working with the individual processes (tasks). Note, however, that in general it is best not to attempt to restart individual applications and tasks.
Basic Troubleshooting: Symptoms of Trouble
R2003.12.0.1
Landmark
Checking Essential System Processes

Some Unix processes are necessary for OpenWorks to run, because they control some functions in OpenWorks. The information in this section shows you how to check which processes are running, how to start processes that are not running, and how to kill processes that are running incorrectly.
Checking Which Processes Are Running

OpenWorks provides you with two tools to check on the status of processes that are necessary to run OpenWorks a Command Menu that expands to show status and the Environment Status Tool (see the chapter entitled Tools for Troubleshooting on page 17). The expanding Command Menu shows the status of the most vital processes. To check the status of OpenWorks processes, click on the Landmark logo ( ), located on the left side of the OpenWorks Command Menu. The Runtime Status Box appears under the command menu.
Click here to toggle status box
The most critical OpenWorks processes are listed, preceded by a check box. If a check box is green, the corresponding process is running on your system or is available from a server. If the box is red, the process has not been started on your system or is not available from a server. On CDE desktops, a check displayed in a red or green check box indicates that OpenWorks has performed a verification on the status of this resource.
R2003.12.0.1
Basic Troubleshooting: Checking Essential System Processes
Landmark
To toggle the status box off, click on the Landmark logo again. To reinvoke the status box (after pinpointing your problem and correcting it), double click on the Landmark logo. This toggles the status box off and then back on. Red and green check boxes can signify different conditions on servers than on clients. The table on the following page lists these differences.
OpenWorks Runtime Status Box

Process Pointing Dispatcher Server Green. The pointing dispatcher specified for your environment is running. Red. The pointing dispatcher specified for your environment is not running. Oracle Green. Oracle is running. Red. Oracle is not running. Client Green. The specified pointing dispatcher is running as specified for your environment. It may be local and it may be remote. Red. The pointing dispatcher may be dead. Or it may be inaccessible. Red. Client cannot communicate with Oracle on the server. Green. Oracle is running on the server. LAM (License Application Manager) Green. Your system is able to check out licenses via the specified license server. Red. Your system is not able to check out a license through the specified license server. The license server may be dead. Or, it may be inaccessible. Remote Services Daemon (RSvD) Green. RSvD is available on the Oracle server. Red. RSvD is not available on the Oracle server. Network Services Daemon (NetD) Green. NetD is available on the Oracle server. Red. NetD is not available on the Oracle server. Green. Your system is able to check out licenses via the specified license server. Red. Your system is not able to check out a license through the specified license server. The license server may be dead. Or, it may be inaccessible. Green. RSvD is available on the Oracle server. Red. RSvD is not available on the Oracle server. Green. NetD is available on the Oracle server. Red. NetD is not available on the Oracle server.
R2003.12.0.1
Landmark
Starting Processes
Restarting the Database The following procedure will not work if the Oracle database processes are not running. If your expanded Command Menu shows that the database is not running, you will have to start the database processes as explained in Starting/ Stopping System Processes on page 64.
If a process is not running, you can restart it by typing the following from the Unix shell window:
processname 2>/dev/null &
For example, if Motif Window Manager stops operating, as evidenced by the loss the borders around your windows, restart that task by typing (from the Unix shell window):
mwm 2>/dev/null &
This command tells the system to redirect the standard error stream to /dev/null. The ampersand (&) tells the system to run this process in the background. This is done so the process will not lock up the window from which it was started. The process names are as follows:
Process Name pd lam mwm Description Pointing Dispatcher License Application Manager Motif Window Manager -rwxrwx--x Permissions required -rwxrwx--x
R2003.12.0.1
Landmark
Killing Processes
When restarting some individual OpenWorks tasks, you sometimes must kill and restart other tasks as well for OpenWorks to operate properly. The following chart shows the tasks you must kill and restart if you restart certain tasks.
If you restart this: pd mwm You must also kill and restart this: All OpenWorks tasks None
All other tasks can be started without affecting other tasks. Sometimes it is necessary to kill or to stop a process that cannot be stopped by normal means (such as pressing Ctrl-D, or using the Close command from the Windows pull down selection). If this happens, check the process table for the process in question. (See Checking Which Processes Are Running on page 5.) Try This First . . . Before you attempt to kill individual processes, try to exit OpenWorks via the Command Menu. If you are able to do this, use startow to restart OpenWorks from the Console Window. Killing a Process If you are unable to exit and restart OpenWorks, try to kill one or more processes. To stop a process, use one of the commands described below. To stop pd, type:
stop_pd
To kill or stop any other current processes, you must first find out the process ID number. To do this type
ps -ef | grep <processname>
A listing appears showing the process ID. To kill the process, type
kill -9 ####
#### is the process ID number.

8 Basic Troubleshooting: Checking Essential System Processes R2003.12.0.1
Landmark
To kill multiple processes, type the process numbers separated by spaces. For example:
kill -9 #### $$$$ %%%%
####, $$$$, %%%% are three different process numbers. If you attempt to kill a process that is not running, this message appears
kill:####:no such process
Telneting from Another System and Using the Kill Command

If an application hangs and you lose control of the mouse cursor, try killing the process from another workstation on the system. 1. At another workstation on the system, type
telnet <your_machine_name>
2.
When prompted for a login, enter the login you normally use on your machine. The prompt should now show your machines name.
3.
Determine the process ID as described above.

ps -ef
4.
To kill the application, type

kill -9 <PID#>
5.
To exit from the telnet mode, type

exit
The prompt should show the name of the remote machine.
Killing and Restarting X

If you cant kill the application, you may want to try restarting the X server.
R2003.12.0.1
Landmark
On a Solaris System 1. To determine the process ID number for the X server, type
ps -ef|grep mwm ps -ef|grep .xinitrc.r5
2.
To kill X, type
kill <PID#>
Do this for both processes found in step 1. This should return you to a white screen. 3. To restart X windows, type
startserver
You may find you need to log out by typing exit, then login with your user name, and then use the startserver command. On an IBM System 1. To determine the process ID number for the X server, type
ps -ef|grep X
2.
To kill X, type
kill <PID#>
This should return you to a white screen. 3. To restart X windows, type

startserver
On a Silicon Graphics System On an SGI system, log out and log back in to restart the X server. 1. 2. 3. From the Desktop menu, select the Log Out option. When asked to confirm the logout, select Yes. When the login dialog box appears, select your login ID and click on Log In.
10
R2003.12.0.1
Landmark
Checking Disk Space

To list all of the current hard drive devices and their directory name equivalents with the total, free, and percent-used space for each, type from any Unix shell:
df -k df -I
(Solaris and SGI) (IBM)
All values are shown in blocks where a block equals 1024K bytes. Checking disk space may provide you with information about where you have space problems.
R2003.12.0.1
Basic Troubleshooting: Checking Disk Space
11
Landmark
Last Resort
If all troubleshooting efforts have failed, reboot your system.
Shutting Down the System If you cannot kill the application from another machine, you may want to shut down the system and then reboot it. Shutting down the system is safer than performing a panic halt because it forces your file changes to be written to disk and it closes the open files on your system, preventing them from becoming corrupted. 1. 2. In a remote or local xterm, type su to become superuser. To shutdown your system, type
shutdown <your_machine_name> -h now
A message stating that the system is about to be shut down will be displayed on terminals of users that are logged into your machine. The message will also be posted on the terminals of systems that are mounted to your machine. Moments after the message is posted, your system will be shut down. 3. Once your system is shut down, type boot to reboot it. For more information on the shutdown command, consult the shutdown man page.
Always shut down Oracle before shutting down your system. Shutting down your system while Oracle is running can corrupt the database. Always perform an orderly shutdown of Oracle before shutting down your system.
oracleLeQs|~gSc_WOepcn^0cz^Qs OracleTQQs|~0
12
Basic Troubleshooting: Last Resort
R2003.12.0.1
Landmark
Aborting and Rebooting If your system hangs and you cannot log into it remotely, you may have to abort and reboot. Aborting and rebooting is a risky way to restart your system because it does not force your file changes to be written to disk and it does not close the open files on your system. As a result, if you abort and reboot, you risk losing changes and corrupting open files. This is a particular danger for an Oracle server. Before you abort, make sure that the system is truly dead. It is possible that you are experiencing a network problem, which could cause delays in system activity. If this is the case, wait until the network server responds. The following instructions explain how to abort and reboot.
On a Sun system
1. Hold down the Stop key and press a. You will receive a message prompting you to reboot the system. 2. In response to the message, press b for boot.
On an IBM system
Press the reset button on the tower.
On a Silicon Graphics system

Press the reset button. When rebooting is completed, restart OpenWorks and SeisWorks
Do not abort and reboot unless instructed to by a Landmark customer support representative. Shutting down your system while Oracle is running can corrupt the database. You may have to restore your database from the most recent backup. In this case, you will lose the changes that you have made in the interval.
R2003.12.0.1
Basic Troubleshooting: Last Resort
13
Landmark
Where to Look for More Help

The preceding pages describe some basic steps you can take to resolve problems with your system. Some problems, however, are more complex and require more intensive action. The chart below describes various types of problems and their symptoms and refers you to the appropriate section of the manual to help you in resolving problems.
Type of Problem Data Access Display Symptoms trouble accessing projects or data trouble displaying well, curve, or fault data problems with importing or exporting data problems with seismic displays, such as snow or gaps in seismic lines problems with color display trouble with computed contours or well displays system processes not running trouble with the X Window system problems starting SeisWorks Oracle processes not running inability to access the Oracle database Troubleshooting Oracle Problems on page 71 Troubleshooting System Problems on page 63 Troubleshooting Seismic Display Problems on page 57 Refer to Troubleshooting DataRelated Problems on page 25
General System Problems Oracle
14
Basic Troubleshooting: Where to Look for More Help
R2003.12.0.1
Landmark
Other Useful Information

Three other chapters in this manual can be useful when you are attempting to solve system problems.
Chapter Tools for Troubleshooting on page 17
Description Describes the OpenWorks utilities you can use to verify that system processes are running. These tools can help you pinpoint the causes of problems Contains the procedure for setting your systems level of error message reporting and describes typical system error messages.
Common Error Messages on page 93
R2003.12.0.1
15
Landmark
16
R2003.12.0.1
Landmark
Tools for Troubleshooting

OpenWorks provides several tools to help you check the status of your Oracle database and to troubleshoot problems in your OpenWorks environment, as follows: Environment Status Tool on page 18. Checks if the environment is correctly configured for OpenWorks and the Oracle system. Project Query on page 20. Uses SQL to query the current Oracle database on the size, location, and user accessibility of a particular OpenWorks project. Using LGC_DEBUG for SeisWorks Problems on page 22. Describes the LGC_DEBUG utility, which allows you to produce a report of files accessed by SeisWorks. This report can help you determine causes of data access problems.
R2003.12.0.1
Tools for Troubleshooting: Whats in this Chapter
17
Landmark
Environment Status Tool

The Environment Status Tool lets you check if your environment is correctly configured for OpenWorks and underlying RDBMS. It provides information about key elements of the runtime environment, system resources, and system configuration. The Environment Status Tool assumes there are no RDBMS-related problems. For this reason, before you invoke the Environment Status tool, you should confirm that Oracle is installed and functioning correctly. To open the Environment Status tool from the OpenWorks Command Menu, click on Utilities Environment Status Tool. The following window appears.
18
Tools for Troubleshooting: Environment Status Tool
R2003.12.0.1
Landmark
Checking the OpenWorks Environment

The first thing that you should do when you have a problem displaying your wells is to determine whether the Oracle database is properly installed and running. Next, you should consult the Environment Status Tool to determine whether the OpenWorks environment is properly configured. Select Status System from the menu bar of the Environment Status Tool. The System Status Menu appears.
R2003.12.0.1
Tools for Troubleshooting: Environment Status Tool
19
Landmark
Project Query
The Project Query tool lets you check the location, size, and user accessibility to database tablespaces for a project. You do not need to be assigned user access in order to query the database about a particular project. Project Query will provide information about any of the Oracle projects in the database. You invoke Project Query as follows. 1. In the OpenWorks Command Menu, click on Project Project Admin. The Project Administration dialog box appears. In the Project Administration dialog box menu bar, select the project of interest and then click on Project Query. You will receive a window similar to the one shown below.
2.
Project Query has a number of read-only information fields that provide details about the size, space, and accessibility of the Oracle project. Many of the entries in this dialog box refer to the project
20
Tools for Troubleshooting: Project Query
R2003.12.0.1
Landmark
tablespace. This is the disk space allotted to the project by Oracle. The following table explains the meaning of each field: Project Query Fields
Field Name Project Availability Project Default Table Extent Parameters Description Project status. Currently, the only status available for this field is ONLINE. The tablespace consists of one or more files. To store data for a particular table within the tablespace, space is allocated in blocks called a extents. When a table is created, it is allocated an initial extent. As data is added, if the current extent is used up, an additional extent is allocated. A size may be specified for the initial extent and for the second extent allocated (or the Next Extent). All subsequent extents will be allocated in the size of the Next Extent. If a Percent Increase has been specified, all subsequent extent allocations will be a certain percent larger than the previous one. Tablespace File Directories, names, and sizes of files that collectively make up the tablespace. You use these names in SQL queries. When you create an OpenWorks project, you are given the option of making a small, medium, or large project. These result in tablespace sizes of approximately the following sizes: small = 60 MB medium = 100 MB large = 200 MB You can add disk space to the existing tablespace using the Project Administration: Modify option. Free Space Available Number of Tables Project Users Space available for additional project data in the tablespace. Number of tables in the tablespace. The names of users currently granted access to the Oracle project. Each name listed with the category of access that has been granted to the user. BROWSE entitles the user to look at the project. INTERP entitles the user to create, view, modify, and delete their own data. MANAGE entitles the user to delete, modify, backup, and restore projects, as well as create, view, modify, and delete project data. It also allows the user to add, update, and delete project users.
For more information on Oracle and Oracle troubleshooting, refer to Troubleshooting Oracle Problems on page 71.
R2003.12.0.1
Tools for Troubleshooting: Project Query
21
Landmark
Using LGC_DEBUG for SeisWorks Problems

The environmental variable LGC_DEBUG produces a report on files as they are accessed by the SeisWorks input/output system. This information may assist you in identifying a variety of problems. For example, if it shows that all attempts to open the project definition file have failed, you know immediately to check the permissions on and location of that file.
Activating/Deactivating LGC_DEBUG
To activate LGC_DEBUG, you set it and start SeisWorks from the same xterm window. The commands differ slightly, depending on which type of shell you are using. In a Bourne Shell To set LGC_DEBUG, use the following commands:
LGC_DEBUG=1 export LGC_DEBUG
To turn off LGC_DEBUG, type

unset LGC_DEBUG
In a C Shell To set LGC_DEBUG, use the following commands:

setenv LGC_DEBUG 1
To turn off LGC_DEBUG, type

unsetenv LGC_DEBUG
22
Tools for Troubleshooting: Using LGC_DEBUG for SeisWorks Problems
R2003.12.0.1
Landmark
Using LGC_DEBUG
To use LGC_DEBUG to diagnose problems, perform the following steps. 1. In an xterm, set LGC_DEBUG to 1, using the appropriate script for your systems shell. (See above.) Start SeisWorks from that same xterm by typing
s2d (SeisWorks/2D)
2.
or
s3d (SeisWorks/3D)
3.
When you encounter some problem in running SeisWorks, check the input/output report in the xterm window. Perhaps the program is unable to open a needed file.
Example of Output
An example of the kind of output LGC_DEBUG produces when you start SeisWorks/3D is shown on the following page. Note that the program searches all project directories for each file (/pa, /pb, /pc, etc.). So you see many failed attempts to open the file before the program tries the right directory. This is normal. The problem occurs when all attempts to open a particular file fail.
R2003.12.0.1
23
Landmark
Beginning of LGC_DEBUG Output for a Successful SeisWorks/3D Session
24
R2003.12.0.1
Landmark
Troubleshooting Data-Related Problems

Well, curve, seismic navigation, and fault data are stored in OpenWorks projects. If you are having trouble displaying wells or faults, you need to check that the database is working and that your system is properly configured to run it.

OpenWorksb Oracle setup ke0 Oracle s XS0 This chapter provides solutions for problems related to accessing projects and project data. This chapter contains the following sections: Data Troubleshooting Checklist on page 26. This section contains steps you can take to check for problems in your OpenWorks or Oracle setup. Oracle Environment Variables on page 35. This section describes the environment variables that must be set for Oracle to function properly. Troubleshooting Data Access on page 36. This section contains solutions for common data access problems in OpenWorks and SeisWorks. Problems with Horizons in SeisWorks on page 47. This section discusses problems associated with creating and manipulating horizons in SeisWorks Problems with Faults in SeisWorks on page 49. This section describes solutions for fault data problems in SeisWorks. Problems Exporting Data from SeisWorks on page 51. This section discusses problems you might have exporting SeisWorks data to Z-Map Plus. Checking the Continuity of SeisWorks/2D Data Files on page 52. This section contains the procedure for using the contest2d utility to check the continuity of 2D master projects. Data Loading Problems on page 54. This section provides solutions to problems that can occur after loading data into a project.
Troubleshooting Data-Related Problems: Whats in this Chapter 25
OpenWorksTSeisWorksN ,epcn[XSQehH0
SeisWorks\BOM0
SeisWorkse\B0
SeisWorksepcnQ0
SeisWorks/2Depcne NN`'0
R2003.12.0.1
Landmark
Data Troubleshooting Checklist

Follow the procedures in this section to check for common problems in the OpenWorks and Oracle setup.
SeisWorks Users: Do You Have an OpenWorks Project?

Verify that your seismic project is linked to an OpenWorks project. This association is recorded in the plist.dat file, which typically is in $OWHOME/conf. 1. In an xterm window, type
plist
You will receive a list of all available Seisworks projects and their corresponding OpenWorks projects. The SeisWorks projects are listed in the left column. The OpenWorks projects are listed in the right column. 2. Confirm that an OpenWorks project is paired with your seismic project. If none is, use Seismic Project Associate (available from the Seismic Project Managers Project menu) to associate an OpenWorks project with the seismic project. SeisWorks/2D users can find more information in the Master Projects and Working Projects chapters of the SeisWorks/2D Project Management manual. SeisWorks/3D users should refer to the 3D Projects chapter of the SeisWorks/3D Project Management manual. 3. If an OpenWorks project is listed for your seismic project, your problem may be that Oracle does not recognize you as a user for this project. In this case, perform the following steps: Use the Project Query option in the Project Administration utility to determine if you are set up as an Oracle user for the project (see the OpenWorks Data Management manual for more information on Project Administration). If Project Administration does not work, you have a problem in your Oracle or OpenWorks setup. Proceed to All Users: Is Your OpenWorks Environment Properly Configured? on page 27.
26
Troubleshooting Data-Related Problems: Data Troubleshooting Checklist
R2003.12.0.1
Landmark
If you are not a valid user, get the project manager to grant you user access. If you are a valid user, then the problem lies either with your OpenWorks environment or with the Oracle setup. Proceed to All Users: Is Your OpenWorks Environment Properly Configured? below.
All Users: Is Your OpenWorks Environment Properly Configured?

After verifying that you have user access to a valid OpenWorks project, you should look for errors in the way OpenWorks is set up. Here are a few quick steps to check the OpenWorks configuration. 1. First, determine if the location of the OpenWorks runtime directory is properly defined by the $OWHOME variable. To do this, type the following command:
lgc_getenv OWHOME
The response should be the top directory of your OpenWorks installation. 2. If OWHOME is not properly defined, perform the following steps: Using vi or another editor, set the value in your initialization file ($HOME/.lgclogin or $HOME/.lgcprofile). Log out. Log in. Start OpenWorks. 3. The OWSYSSID variable must also be set properly. To check this variable, type the following command:
lgc_getenv OWSYSSID
The response should be the name of the Oracle instance where the OpenWorks system database is located. By convention, the name of the Oracle instance is the node name preceded by ow. Example: for the node nova, the OWSYSSID would be ownova.
R2003.12.0.1
27
Landmark
4.
If necessary, set OWSYSSID to a correct value either by using the Project Status tool or according to the following steps. Using vi or another editor, set the value in your Landmark configuration file ($OWHOME/conf/lgcenv.cf). Log out. Log in. Start OpenWorks.
5.
If NetD is not running, you will be able to access Oracle projects, but you will be unable to create, modify, or delete projects using Project Administration or Project Create. RSvD allows OpenWorks applications to access services on remote machines. To check that the Network Services Daemon (NetD) and Remote Services Daemon (RSvD) are functioning, perform the following steps: In the OpenWork Command Menu, click on the Landmark logo to invoke the Runtime Status Box. Look for a green check box next to Network Services Daemon and Remote Services Daemon, indicating that the daemons are operating. If the check boxes are red, query whether the daemons are running. Use the following commands (Solaris, SGI, and IBM):
ps -ef | grep netd checkRSvD
If NetD is not running, start it by typing this command:

start_netd
This should also restart RSvD. RSvD can be initiated only by NetD.
28
R2003.12.0.1
Landmark
6.
If, after performing all these checks, you still have trouble accessing the Oracle project, proceed to All Users: Can You Access Oracle? below.
NetD is required on database client machines for Dynamic PD. If your machine is a database client, the Network Services Daemon needs to be running locally if Dynamic PD is running. NetD must also be configured and operational on the host machine that is the database server.
All Users: Can You Access Oracle?

At this point you know that you have a valid OpenWorks project, but you cannot reach the Oracle database from within SeisWorks. The next step is to query Oracle directly using SQL (structured query language). If this attempt fails, you will know that the problem lies in the Oracle setup. 1. First, check that the environment variable OWSYSSID is properly set. Type this command:
lgc_getenv OWSYSSID
The response should be the name of the Oracle instance where the OpenWorks system database is located. By convention, the name of the Oracle instance is the node name preceded by ow. Example: for the node nova, the OWSYSSID would be ownova. 2. If necessary, set OWSYSSID to a correct value either by using the Project Status tool or according to the following steps. Using vi or another editor, set the value in your Landmark configuration file ($OWHOME/conf/lgcenv.cf). Log out. Log in. Start OpenWorks. 3. If OWSYSSID is properly set, use its value to query the Oracle database. Type this command:
sqlplus owsys/owsys@<OWSYSSID>
You should get an SQL prompt, indicating that you are now in SQL and can view data in the database.
R2003.12.0.1 Troubleshooting Data-Related Problems: Data Troubleshooting Checklist 29
Landmark
4.
If your SQL query is not successful, you need to check whether your command reached the correct sqlplus. Issue the following two commands:
which sqlplus [system responds with a path] echo $ORACLE_HOME/bin/sqlplus [system responds with a path]
The which sqlplus path should point to the same location as does the echo command. If it does not, the system administrator may need to redefine your $PATH environment variable. Then repeat Step 3 and continue from there. If the two paths are the same, you have a problem with your Oracle setup. Oracle may not be running, or the SQL Net Listener may not be running. Proceed to Step 9. 5. If your SQL query is successful, but you are having trouble accessing the database under your own user name, the problem may be that you are not established as a valid Oracle user. Perform the following steps: Change directories using the following command:
cd $OWHOME/bin
Switch users to the oracle administrator with the following command:

su - oracle
Invoke the Oracle Database User Management tool with the following command
orauser
The Oracle Database User Management tool should appear in the xterm. 6. Choose Option 4, Show Externally Identified Users of the Oracle Database. A list of valid Oracle users appears. If you are not in the list of Oracle users, press Return and then choose Option 1, Adding a user to the Oracle Database. Follow the prompts to add yourself as an external user.
7.
30
R2003.12.0.1
Landmark
8.
Now you must become a project user for the OpenWorks project of interest. Use Project Query in the Project Administration utility to identify a project user with manager status, and get that user to grant you access to the project. To check the status of the Oracle environment in Solaris or IRIX, select System and then Database Sanity Checker from the OpenWorks Command Menu. The Database Sanity Checker appears. From the menu bar of the Database Sanity Checker, select Option and then Oracle. The Oracle Setup dialog box appears, with information about essential Oracle environment variables, files, and processes. Check that the environment variables are properly set. Use the following guidelines: ORACLE_HOME should be set to the top-level directory of your Oracle installation. (The default setting is $OWHOME/ oracle.) Also, ORACLE_HOME must point to the actual Oracle directory, not to a link. To check this, go to $OWHOME and issue an ls -l command; this listing will show if a link exists. ORACLE_SID should be set to the system ID for the database server your system will be accessing. If either of these Oracle environment variables is not set correctly, set it using the following steps. Using vi or another editor, set the value in your initialization file ($HOME/.lgclogin or $HOME/.lgcprofile). Log out. Log in. Start OpenWorks.
9.
R2003.12.0.1
31
Landmark
In the Oracle Setup dialog box, check that the following Oracle processes are running. Recovery Process Process Monitor System Monitor Database Writer Log Writer
In a client-server configuration, check processes on the server. If your machine is a client and you get Oracle from a remote server, the Database Sanity Checker will show all Oracle processes as not running (as indicated by a red radio button). This is normal. To check the Oracle processes, you must invoke the Database Sanity Checker from the server where Oracle resides. Perform the following steps: Telnet to the server. Set the DISPLAY variable to display on your machine. Start the Database Sanity Checker with the following command: $OWHOME/bin/xdbsanchk
If any of the five Oracle processes are not running, shut down Oracle and restart it. Use following commands:
su - oracle dbshut dbstart
If the SQL*Net V2 Listener Process is not running, OpenWorks applications will not function. To start the listener, use the following commands:
su - oracle lsnrctl start quit
Both Oracle and OpenWorks can function without Archiver being activated.
32 Troubleshooting Data-Related Problems: Data Troubleshooting Checklist R2003.12.0.1
Landmark
10. If you cannot access the database with all essential processes running, the problem may be that your machine is a client to an Oracle server, and the server is not listed in your tnsnames.ora file. To check this, perform the following steps: To learn the name of your Oracle server, type
lgc_getenv OWSYSSID
Change directories to $ORACLE_HOME/network/admin. Look at the tnsnames.ora file for an entry like this:
where owtenson is the system ID of the server being accessed. If no such entry exists, or if the existing entry is incorrect, see the OpenWorks System Administration manual set for complete instructions on modifying the tnsnames.ora file. You have now verified the following: The Oracle environmental variables are properly set. Oracle is running. SQL Net Listener is running. You are a valid Oracle user. The Oracle processes are running. Your system is properly defined in the tnsnames.ora file (if necessary).
11. If you still cannot access the database, the problem may be an incorrect Oracle listener port. To check this possibility, select Utilities and then Environment Status Tool from the OpenWorks Command Menu. The Environment Status Tool appears. 12. From the menu bar of the Environment Status Tool, select Status and then Oracle. The Oracle Status Menu appears.
R2003.12.0.1
33
Landmark
13. Note the numeric value for Listener Port. 14. Check that this same value is recorded in the file /etc/services. This file should have an entry like the following:
tnslsnr 1521/tcp # SQL*Net version 2 listener
In this example, 1521 is the number of the Oracle Listener Port as posted in the Environment Status Tool. 15. If /etc/services does not have a tnslsnr entry, add one, or contact your system administrator for assistance. 16. If the Oracle setup checks out and you still cannot access the database, contact your Landmark customer support representative for assistance.
34
R2003.12.0.1
Landmark
Oracle Environment Variables

The following variables must be set in order for OpenWorks to run the Oracle database successfully. These variables will be set when you use the standard Landmark installation procedures to install OpenWorks 2003.12.0.1 and Oracle.
Variable ORACLE_HOME Where Set C shell: $HOME/.lgclogin Korn or Bourne shell: $HOME/.lgcprofile Purpose Defines pathname of the Oracle directory. The default is $OWHOME/ oracle. Specifies the system ID of the default Oracle instance to be used. In most Oracle installations, ORACLE_SID is set to the same ID as OWSYSSID. Identifies the system ID of the host on which the OpenWorks 2003.12.0.1 Oracle instance is installed. By convention, you usually specify OWSYSSID as the name of the host prefixed by ow. For example, for a host named nova, OWSYSSID would be specified as ownova. OW_DBTYPE (optional) Default: $OWHOME/conf/lgcenv.cf Also can be set in the Unix initialization files as follows: C Shell: $HOME/.lgclogin Korn or Bourne shell: $HOME/.lgcprofile Indicates which database OpenWorks is installed on. For OpenWorks 2003.12.0.1, this variable is set to Oracle.
ORACLE_SID
C Shell: $HOME/.lgclogin Korn or Bourne shell: $HOME/.lgcprofile
OWSYSSID
Default: $OWHOME/conf/lgcenv.cf Also can be set in the Unix initialization files as follows: C Shell: $HOME/.lgclogin Korn or Bourne shell: $HOME/.lgcprofile
R2003.12.0.1
Troubleshooting Data-Related Problems: Oracle Environment Variables
35
Landmark
Troubleshooting Data Access

The OpenWorks 2003.12.0.1 data access system is a database or table schema called OWSYS. Information about OpenWorks 2003.12.0.1 projects is kept in OWSYS so that multiple users can have access to the same projects. If you are having problems with the data access system, such as connection failures or failure to find or open a project, try the following checks.
Data Access Problems in OpenWorks

The following data access problems may occur in OpenWorks 2003.12.0.1 installations using Oracle. For more detailed information on Oracle troubleshooting, see Troubleshooting Oracle Problems on page 71. Environment Variables Are Not Set Properly The data access environment variables must be set correctly. Use the Environment Status Tool to check them. The OWSYSSID should be the name of the machine where the system database resides. If a variable is not set correctly, then check the value of the OpenWorks environment variable OWSYSSID. To get this value type:
lgc_getenv OWSYSSID
If the node name is not the same as the node where OWSYS is found then you need to edit the file $OWHOME/conf/lgcenv.cf and correct the OWSYSSID designation so that it has the letters ow followed by the correct node name. For example, if the correct node name is nova:
OWSYSSID ownova
OWSYS Does Not Exist or Cannot Be Found Check that OWSYS exists on the node specified by the OWSYSSID environment variable. Do this by logging on to the node where OWSYS should exist and entering the following command:
sqlplus owsys/owsys
36
Troubleshooting Data-Related Problems: Troubleshooting Data Access
R2003.12.0.1
Landmark
The system should make a connection. If it does not, be sure that Oracle is properly installed and running (see the Troubleshooting Oracle Problems on page 71 chapter). Also check that you have access from a remote node. To do this, log in to a remote node that should have access to the node where owsys database exists.
sqlplus owsys/owsys@value_of_owsyssid
If this fails to connect, check that Oracle is running properly at each node. If that is the case and you are still unable to connect, then you should check that the network privilege to connect between the two nodes is properly set in Oracle. OWSYS May Not Have Been Properly Created Once you are in OWSYS you should check to see that the OpenWorks tables exist.
sqlplus owsys/owsys select table_name, tablespace_name from all_tables where owner = 'OWSYS';
You should receive a list of over 30 tables. A Project Database Exists in Oracle, But Is Unknown to OpenWorks First check that OWSYSSID is set properly. If it is set properly then the next step is to check that the tables in OWSYS have the proper values. There are three tables that should contain information describing a project: ow_sys_project, ow_sys_min_max, and ow_sys_pal. The ow_sys_project and ow_sys_min_max tables should have one entry for each project. The name for a project must be unique. The ow_sys_pal should have at least one entry per project. This entry is the project manager with security level set to 3.
sqlplus owsys/owsys select * from ow_sys_project; select * from ow_sys_prj_user;
If the project in question has been deleted from OpenWorks but still exists in Oracle, see also A Project Fails to Delete Completely on page 41.
R2003.12.0.1
37
Landmark
The Data Access System Cannot Find the Data Files The data access system must have two data files located in the $OWHOME/dat/idb directory. These files are sql.dat.oracle and xref.dat. If these files are not found, the GDI initialization will fail and return an error on the command line:
PROBLEM PROCESSING DATABASE CROSS REFERENCE FILE: $OWHOME/dat/idb/xref.dat
or
PROBLEM PROCESSING SQL FILE: $OWHOME/dat/idb/sql.dat
If the ERR_LEVEL environmental variable is set to 2 or less, then an error statement is produced:
gdiInit.c:145 217600017 gdiInit: idb_init failure
or
gdiRead.c:365 217600003 gdiRead: Bad sql query
Use the Environment Status Tool to find the $OWHOME variable. Locate and move sql.dat and xref.dat into the $OWHOME/dat/idb directory to correct this problem. Make certain that these files have read access permission. Check this with the command
ls -l $OWHOME/dat/idb
A screen response should be similar to:

total 489 -rw-r--r-- 1 owadm 198670 Dec 2 20:33 sql.dat.ingres -rw-r--r-- 1 owadm 198444 Dec 2 20:33 sql.dat.oracle -rw-r--r-- 1 owadm 73776 Dec 2 20:32 xref.dat
If three rs do not exist in the second entry for each file, access may be denied to these files. To correct this situation, on the command line enter
chmod 444 *.dat
38
R2003.12.0.1
Landmark
A Data Access Failure Occurs If relations exist between database verification tables, yet these relations are not specified, then the entire access may fail. For example, if an attempt is made to read a casing instance without a formation name and the vc_stratunitname has no UNKNOWN entry, then the access will fail. The verification tables (VC) have an ID and a name as their basic components. There must be one entry that has an ID of zero value and a default name of UNKNOWN, so that unspecified relations can return this instance, allowing the entire access to succeed. For example, the vc_stratunitname table needs an entry
strat_unit_name_id = 0 strat_unit_name = UNKNOWN
This allows successful access of a casing without having to specify the formation name. A Depth Preference Is Not Set If unexpected depth values are set, the depth preference may not be set. The default is the project depth units and measured depth. A Priority List is Not Set If no priority list is set and an api routine uses the priority list, then an error message will occur:
Priority list has not been set
If the priority list is not alphanumeric, an error message is produced:

Priority list not alphanumeric
If the priority list is too long, an error message is produced:

Priority list has entry too long or without null terminator.
R2003.12.0.1
39
Landmark
You Are Not the Owner of a Data Type There are certain data types that check for ownership when a modification is being made. These are Calculated Lithology Calculated Lithology Header Horizon Parameters Interpreted Drilling Show Pick Well List Well Note Pad Zone Zone Attribute Zone Detail
If an update or deletion is attempted by a user who does not own the instance, then error messages occur if the ERR_LEVEL is set at 0 or 1.
Not owner, cannot delete.
or
Not owner, cannot update.
Check ownership in Well Data Manager. Ancillary Messages That Can Be Ignored The following messages can usually be ignored:
117600004: gdiReadWellPick: idb_fetch_structure failed 117600016: gdiAdd completed successfully
The numbers are what are important.
40
R2003.12.0.1
Landmark
A Project Fails to Delete Completely On rare occasions, a project you delete in OpenWorks may fail to completely delete from the Oracle database, although the name no longer appears in any project list. In that event, you cannot use that project name again with a project create or restore command. In this circumstance, the following commands can be issued to manually delete all remnants of the project from the database. This approach should be used only by the Oracle database administrator and only on any rare occasion when a normal project delete has not succeeded. 1. Login as the Oracle DBA account owner (e. g., oracle) and use the Server Manager utility to access the privileged Oracle user called internal:
login: su - oracle password: DBA_Password svrmgrl connect internal
2.
Now issue all commands needed to fully delete the project PROJECTNAME from the database (here, indented lines represent wrapped lines):
alter session set current_schema=owsys; delete from ow_sys_project where project_name=PROJECTNAME; delete from ow_sys_prj_delete where project_name=PROJECTNAME; delete from ow_sys_prj_user where project_name=PROJECTNAME; delete from ow_sys_prj_archive where project_name=PROJECTNAME; delete from ow_sys_prj_bkup_log where project_name=PROJECTNAME; delete from ow_sys_prj_bkup_freq where project_name=PROJECTNAME; delete from owsysp.ow_sysp_prj_security where project_name=PROJECTNAME;
3.
You must also delete all tablespace related to the project. First, locate the Project.dbs file:
connect internal select * from dba_data_files;
R2003.12.0.1
41
Landmark
4.
Make note of the path to the project data file (i.e., the location of the Project.dbs file). Issue the following commands to complete the deletion and to exit:
drop tablespace PROJECTNAME including contents cascade constraints; drop user PROJECTNAME cascade; drop role manage_PROJECTNAME; drop role interp_PROJECTNAME; drop role browse_PROJECTNAME; drop role I_interp_PROJECTNAME; exit
5.
6.
Finally, change to the directory where the Project.dbs file is located, and remove it.
cd <path_to_proj.dbs> rm Project.dbs
42
R2003.12.0.1
Landmark
Data Access Problems in SeisWorks

When you move interpretations from 2DPlus or 3DPlus to SeisWorks, you could encounter problems when trying to access the old data files. This section describes the solution to these problems. Your Project Does Not Appear If you press List in the Main Menu window and your project does not appear in the Project Selection dialog box, perform the following steps: 1. In an xterm window, type this command:
plist
A list of all your SeisWorks projects and their associated OpenWorks and master projects will be displayed. 2. If the missing project is not listed, edit the plist.dat file. (This is the file from which the list of available projects is generated.) Change directories to $OWHOME/conf Use vi to edit plist.dat and add the project. 3. Check that the project directories exist and have open permissions. If the problem is permissions, use the following command to recursively give open permissions to each directory and its subdirectories. You must have superuser status when you issue this command:
chmod -R 777 <directory_name>
If the project directories are missing, reload them from a backup tape. 4. Check that the project definition file (.ps2 in SeisWorks/2D or .pds in SeisWorks/3D) is in the project sys directory and has open permissions.
Problems with 2DPlus Files In 2DPlus every data file you created was owned by lgc and had a user ID of 200 and a group ID of 10. Now, in SeisWorks/2D you have the latitude to establish different user and group IDs.
R2003.12.0.1
43
Landmark
If SeisWorks users are using different accounts besides lgc with different user and group IDs, they may run into permission problems when they try to access old 2DPlus files. Simply change the permissions to grant open access as described in Changing the Permission Mode of a File below. Problems with 3DPlus Files In 3DPlus, every data file you created was owned by lgc and had a user ID of 200 and a group ID of 10. Now, in SeisWorks/3D you have the option of establishing different user and group IDs. If you are using different accounts besides lgc with different user and group IDs, you may run into permission problems when you try to access old 3DPlus files. Simply change the permissions to grant open access. For instructions on checking and changing permissions, see Changing the Permission Mode of a File below. Changing the Permission Mode of a File Permissions are assigned to both directories and files. The permission mode of a directory determines whether users can read or write to the files in the directory. The permission mode of a file determines whether users can read, write to, or execute the process specified by that particular file. Users belong to three different categories: (1) the owner of the file, (2) the group to which the owner belongs, and (3) all others. If you are denied permission to read or write to the files in a directory, or to read, write to, or execute a particular file, chances are that you must change a permission mode. You can change the permissions assigned to a particular directory or file only if you are the owner of the directory or file, or you have superuser status.
Examining the Currently Assigned Permissions

To view the current permission mode of a file, cd to the directory containing the file and use the ls -lag command to display information about the files in the directory. You will receive a display that resembles the following screen.
44
R2003.12.0.1
Landmark
Permissions: owner group all others
(column 1)
name of owner name of group
Column 1 indicates whether the file is a directory, a file, or a link. A dash () indicates that the file is a file. A d indicates that the file is a directory. An l indicates a link to a file or directory. Columns 2 through 4 indicate the permissions for the user. Columns 5 through 7 indicate the permissions for the group to which the user belongs. And Columns 8 through 10 indicate the permissions for all other users.
R2003.12.0.1
45
Landmark
To determine what permissions are currently assigned to the different user types, use the following table.
Permission code r w x Description Allows prospective user to read the file. Allows prospective user to write to or modify the file. Allows the prospective user to execute the file. This option only applies to files that are executables. Denies access of the particular type indicated by the respective column. That is, if a dash () appears in a read column, the read permission is denied. If it appears in a write column, the write permission is denied. If it appears in an execute column, the execute permission is denied.
Customizing Permissions for Different User Types

You can change the permissions assigned to particular user types with the following chmod command.
chmod <user type><operator><permission code><filename>...
The variables that can be used in this command are described in the table below.
Variable <user type> Description Specifies which of the user types is to be affected by the permission change. Valid codes for user types: u is the owner, g is the group, and o is all others. Specifies whether permissions are to be granted or denied. Valid options: + indicates that the permissions are to be granted; - indicates that the permissions are to be denied. Specifies the type of permission to be granted or denied. Valid codes: r applies to read privileges, w applies to write privileges, x applies to execute privileges. Names the directory or file(s) to which the permissions are to be applied. If <filename> is the name of a directory, the chmod operation determines which users can read or write to the files in the directory. If <filename> is the name of a file, the chmod operation determines which users can read, write to, or execute the file.
<operator>
<permission code> <filename>
46
R2003.12.0.1
Landmark
Granting Read, Write, and Execute Permissions to All User Types

If you are the owner of a directory or file, you can grant read, write, and execute permissions to all user types by using the following command
chmod 777 filename...
This method uses the octal number 777 to assign permissions. The octal number method of assigning permissions is described in the online man pages for chmod (which you can view by typing man chmod at a system prompt). To change the permissions within a particular directory and apply the changes to all subdirectories and their files, you can use the following recursive chmod command.
chmod -R 777 filename...
Problems with Horizons in SeisWorks

The following techniques can help you resolve problems with SeisWorks horizons or horizon files.
Cannot Make Another Horizon

If you receive an error message notifying you that you cannot make another horizon: Check for duplicate horizon data (.hzd) files. If you find duplicates, delete them. Check that the horizon catalog (.hrz_cat) exists. If it does not, create one with the crtcat utility. Check whether you have exceeded the limitation of 4096 horizons currently in the working project. If you have, you must use an existing horizon plane, since the 4096 horizon limit is arbitrary and irreversible. Eliminating existing horizons will not enable you to add additional horizons. Instead, find a horizon that you no longer need. Display the horizon in the Map View and use the Areal Delete option to delete the interpreted data that is currently correlated with the horizon. Use the Attributes option in the Seismic View to rename the horizon. Reinterpret the horizon.
R2003.12.0.1 Troubleshooting Data-Related Problems: Problems with Horizons in SeisWorks
47
Landmark
Horizon List Incorrect or Missing

SeisWorks/2D First, check to see if the horizons are still in the master project but simply not appearing in your working project. Select Horizons Global Manager Global Add to Project. If the horizons you need are listed, select them for your working project. If the horizons of interest are not listed in the Global Add to Project dialog box, check to see if both horizon header (.hzh) and horizon data (.hzd) files are contained in the master project. If the data files are present but the header file is missing, simply creating the horizon once again within SeisWorks may solve the problem. But if the data files are missing, you will have to reinterpret the horizon or load it from a backup tape. Check the dir.dat file to make sure that all the master project filesystems are in directories with the global designation. If these filesystems have somehow been moved to directories that are not global, you cannot access the files you need to display and work with horizons. Move the master project filesystems to a global directory. If dir.dat is not properly specified or your global area is not properly defined for the project, the horizons will be marked as deleted in the horizon catalog (.hrz_cat). Correct the problem with dir.dat or the global area, and then simply use the Global Manager to restore your horizons to the working project. SeisWorks/3D If you find some of your horizons missing, try rebuilding the horizon index file (.hrz) using the HrzUtil utility. See the HrzUtil chapter of the Seismic Project Utilities manual for detailed procedures. 1. 2. Exit SeisWorks/3D. In an xterm window, enter the following command:
HrzUtil
3.
When the HrzUtil dialog window appears, select the 3D radio button and click on List. From the popup Project Selection dialog box, highlight your project and click OK.
48
Troubleshooting Data-Related Problems: Problems with Horizons in SeisWorks R2003.12.0.1
Landmark
A list of horizon names, ordered by horizon number, appears in the Horizon List selection box. 4. 5. Select Rebuild Index. When the index has been rebuilt, the horizon list is refreshed. Examine it to confirm that the missing horizon has been recovered. Select Alphabetic if you prefer to view the list in alphabetical order. Select Quit and restart SeisWorks/3D.
6.
Displaying Horizons in Map View

You can have a total of five active horizons for all currently open Map or Perspective Views. Your horizon selections apply to all currently open Map Views, Horizon Image Maps, and Perspective Views. For example, suppose you select bluemax as the first display horizon in the Contents dialog box for Map View 1. Then you select greenmin as the first display horizon in the Contents dialog box for Map View 2. Your last selection will be applied to all the currently open views. If you redraw Map View 1, greenminnot bluemaxwill be displayed there. To avoid this problem, use the second horizon display field when you choose the horizon for your second Map View, the third horizon display field when you choose the horizon for your third Map View, and so on.
Problems with Faults in SeisWorks

Below are some techniques to help resolve problems in working with SeisWorks faults.
Correlating Faults
The following tips address problems with correlating faults in SeisWorks. Fault Plane Not Listed Only faults that have been selected for display are listed in the Correlate dialog box. If a fault you want is not there, close the dialog
R2003.12.0.1 Troubleshooting Data-Related Problems: Problems with Faults in SeisWorks 49
Landmark
box. From the Map View or Seismic View menu bar, select Faults Select, and choose that fault for display. Then reopen the Correlate dialog box. Cannot Assign Fault Heave When you are correlating with fault heaves in Map View, you must click on the fault segment within that heave. The fault heave, which represents the gap in the horizon, may be wider than the fault segment in areal view. So when you click within the heave you may not actually be on the segment, as illustrated below.
fault segment horizon Fault as interpreted in Seismic View. Note that gap in horizon is wider than the area covered by the fault segment as drawn.
areal extent of fault segment
fault segment horizon fault heave Fault as shown in Map View. Note that the width of the heave exceeds the width (areal extent) of the fault segment. When you correlate, you must click on the segment.
Relation of Fault Heave to Fault Segment
If you click within the heave and get a beep, move closer to one side of the heave symbol and click again.
Identifying Faults in Map View

In a Map View, the Identify Faults option works only for faults that have been triangulated. Any change to a fault segment or fault plane makes the existing triangulation of that plane obsolete.
50
Troubleshooting Data-Related Problems: Problems with Faults in SeisWorks
R2003.12.0.1
Landmark
If the triangulation is out of date when you try to identify faults, a message prompts you to retriangulate or exit the identify faults mode. To retriangulate, click on OK. The program retriangulates the fault plane and continues the search to identify faults. This message will also appear if only one fault segment has been assigned to the fault plane. To avoid receiving the message, digitize another fault segment and apply it to the fault plane.
Suspect-Looking Fault Contours

Triangulation connects the digitized points of all fault segments assigned to a particular plane. If you have not picked those segments consistently, the triangulation will be irregular and inaccurate. As a consequence, the fault contours will also be irregular and inaccurate. To avoid this irregularity, keep all segments for a given plane approximately the same length. (That is, digitize the full extent of the fault segment on every section you interpret.)
Problems Exporting Data from SeisWorks

With the Export to Z-MAP Plus option, exporting a large horizon can take considerable time. If an export job fails or appears to fail, use the following strategy to resend your export job. 1. Check to see if the process is still running by typing
ps -ef|grep SNAP
(IBM, Solaris, and SGI)
2.
If the export job is not running, perform the following steps: Check to see if your filesystem has run out of space. Export to Z-MAP Plus creates temporary sorting files (tmp.*) in the project sys directory during an export job. Your horizon may exceed the available capacity. Remove the tmp.* files. Decimate the horizon and convert it to a dataset using the Convert Horizon to Map Points option.
R2003.12.0.1Troubleshooting Data-Related Problems: Problems Exporting Data from SeisWorks
51
Landmark
Export the horizon dataset using the Computed Contours and Fault Polygons option on the Export to Z-MAP Plus dialog box.
Checking the Continuity of SeisWorks/2D Data Files

For a quick check of your 2D master project, use the contest2d utility. This utility tests for continuity of 2D line data, horizon data, and seismic data. It checks to see if each line has a a valid trace range. That is, it checks that the minimum trace is not 0, that the minimum trace number is smaller than the maximum trace number, and that the minimum and maximum trace numbers are not the same. each line has the required navigational files. These are the .st_glb file that defines the shotpoint-to-trace relationship and the .xy_glb file that contains shotpoint real-world locations. every seismic file (.2v2) has read/write permissions. every horizon data file (.hzd_glb) has read/write permissions. every horizon data file (.hrd_glb) has the same trace range as defined in corresponding the line header file (.lh_glb).
As contest2d runs, it outputs to the screen a list of each line examined and the trace range of that line. The utility also generates two files: a log file that lists every file examined, its file size, and its full path an error file that lists any discrepancies encountered during the check.
The log file is useful in compiling a database of the lines in your master project and in keeping track of the size of your master project. The error file may help you identify and resolve problems encountered in displaying seismic or horizon data. See the 2D Continuity Testchapter of the Seismic Project Utilities manual for detailed procedures.
52 Troubleshooting Data-Related Problems: Checking the Continuity of SeisWorks/2D Data Files
Landmark
To run contest2d, do as follows: 1. Set the environment variable LGC_MASTER to the master project you wish to examine by entering the appropriate commands at the prompt: In a C shell: setenv LGC_MASTER <master_project> In a Bourne shell: LGC_MASTER=<master_project> export LGC_MASTER
2.
At the prompt, type

contest2d <log_filename> <error_filename>
Use whatever names you like for the log and error files. If you want to write them to a directory other than the current directory, include the full path. 3. Examine the output on the screen, which will show you each line checked and its trace range. Examine the log file and error file.
4.
R2003.12.0.1Troubleshooting Data-Related Problems: Checking the Continuity of SeisWorks/2D Data
Landmark
Data Loading Problems

This section provides solutions to common problems that can occur after loading data into an OpenWorks project.
General Data Loading Problems

TVD Total Depth for Deviated Wells is Too Shallow Try one or more of the following: Load a position log with TVD values. Load a position log with more stations (depths) recorded along the well path. Load a directional survey (it will calculate TVD values using the radius of curvature method as the default).
Message: Records dropped due to errors This message does not necessarily indicate a problem. When dealing with multiple occurrences of a field, null occurrences can exist after the last data value. The loader cannot write a record with a required field set to null, so it drops that record. Check the error log file to verify.
SeisWorks Data
Wells Appear in 2D Display but not in Map View (SeisWorks) Try exiting and restarting SeisWorks. If that does not correct the problem, try one or more of the following: Make sure that the active OpenWorks project matches the SeisWorks definition. Check x, y coordinates; modify as necessary using SeisWorks World Coordinates utility. Reload well x,y coordinates using a different cartographic reference system.
54
Troubleshooting Data-Related Problems: Data Loading Problems
R2003.12.0.1
Landmark
Well Symbols Appear in 2D Display but not in Map View The Well Status is not recognized by SeisWorks. Edit the status using the OpenWorks Well Data Manager. Wells Appear in Map View but not in Seismic View You are missing one or both of the following: a Time/Depth Table, a Position Log. Wells Appear in Seismic View, but not Curves or Tops You could be missing a Time/Depth Table or using a bad table. You might also need to edit the synthetic to fix the time-depth relationship. Geologists Tops not Appearing Correctly in Seismic View Do one or more of the following: Check the SeisWorks project datum settings. Make sure that KBs are loaded for the wells. Edit the synthetic to fix the time-depth relationship.
Synthetics do not appear in Seismic View Check to see that Synthetics are toggled on in Seismic View: 1) Contents-Log/Synthetic Track; 2) Wells-Parameters-Display Curve; 3) Wells-Select-Synthetics. Also make sure that the synthetic exists over the time range displayed. Often, synthetics have a time reference other than zero depth and require bulk shifting.
R2003.12.0.1
55
Landmark
56
R2003.12.0.1
Landmark
Troubleshooting Seismic Display Problems

This chapter contains solutions to problems you might encounter with displays of seismic data. These problems could include gaps in seismic lines, color allocation problems, or bad displays of computed contours or wells.

This chapter contains the following sections: Problems with Seismic Display on page 58. Contains solutions for common problems encountered while displaying seismic data. Problems with Colors on page 59. Describes steps you can take to solve problems related to the allocation of color for seismic displays. Other Display Problems in SeisWorks on page 60. Discusses solutions for problems with displaying computed contours or wells in map displays.
R2003.12.0.1
Troubleshooting Seismic Display Problems: Whats in this Chapter
57
Landmark
Problems with Seismic Display

Some suggestions for managing problems with your seismic display are discussed below.
No Seismic
SeisWorks/2D Did you select a vertical seismic (.2v2) file? Check the Seismic Parameters dialog box, and select a .2v2 file. SeisWorks/3D If no seismic is displayed at all, you may need to select a vertical, bricked, or compressed seismic (.3dv, .bri, .cmp) file. Check the Seismic Parameters dialog box, and select a seismic file.
Snow or Stripes on Display

If you are trying to display a 16-bit or 32-bit file, and you have not scaled the file to 8 bits, you will receive snow or stripes on the display. See Scaling and Clipping Seismic Data in the chapter Preparing Seismic Views of the SeisWorks/3D Data Display manual for information on how to scale seismic data.
Gaps or White Spots on Seismic Line

Gaps or white spots may indicate problems in the way the data was acquired or processed. Another possibility is that the data was not loaded correctly. If the problem is extensive, you may have to reload the data. Check with your system administrator or data loader. Also, refer to the 2D Project Management, 3D Project Management, 2D Batch Control Monitor, and 3D Batch Control Monitor manuals.
58
Troubleshooting Seismic Display Problems: Problems with Seismic Display
R2003.12.0.1
Landmark
Problems with Colors

Often what appears to be a data problem is simply a problem in displaying that data.
Cant Get Dual Color Bars

When you start SeisWorks, you are asked to indicate whether you want single or dual color bars on each screen. If you get a message saying dual color bars cannot be allocated, you probably do not have enough colors available. Remember other applications are also tapping the color resources. In such a case, you can either run SeisWorks with a single color bar, or you can kill some other applications and then try to start SeisWorks in the dual color bar mode.
No Data Displayed
If you display a horizon or mapping file in the Map View, and nothing appears, display the Color Control dialog box of the screen where the problem is occurring. The problem may be that the Mode option is set to Manual and the data is outside the range of the color bar. If this is the case, set the Mode option to Local and redisplay the horizon or mapping file in the Map View in question.
No Color Maps
Color map files (.clm files) are automatically copied to the project sys directory when you create a working project. Select File Open in the Color Control dialog box to see whether you have color map files. If none are listed in the resulting dialog box, someone has deleted them or moved them out of the system. To restore them, copy the .clm files from $SEISUTILSHOME/dat to your project sys directory.
Partial Data Displayed

If the color bar is not picking up the minimum and maximum values properly, recompute extremes for the horizon. In a Map View or Horizon Image Map, select Horizons Computations Compute Extremes. Then set the color bar to the Local mode and redraw the Map View.
R2003.12.0.1 Troubleshooting Seismic Display Problems: Problems with Colors 59
Landmark
Be sure that in specifying the areal extent for the Compute Extremes computation, you select Entire Survey. If Compute Extremes is run for a limited map area, the color bar will reset to the minimum and maximum values computed for that small area only.
Other Display Problems in SeisWorks

This section contains troubleshooting techniques for computed contours and well data in map displays.
Troubleshooting Computed Contours

The quality and accuracy of computed contours depends on the contouring parameters you have set. If you are dissatisfied with their appearance, adjust the contour parameters and rerun the contouring job. Troubleshooting Computed Contours
Problem Computed contours do not appear in Map View. Possible Solutions Be sure contours are turned on in the Map View Contents dialog box. Check the Color Control contour settings to determine whether the contour range falls within the map point range. Use the View option (Mapping Files View) to do the following: Make sure that you have opened the appropriate mapping file. Check the mapping file to see that the grid exists. Check the grid parameters to determine whether the search radius is too small. Too few or too many contours. Gridded contours are too noisy or jagged. Gridded contours are discontinuous (broken) Reset the Start Time, End Time, and/or Interval settings in the Color Control window and then redraw the Map View. Increase grid size and search radius. Increase search radius.
60
Troubleshooting Seismic Display Problems: Other Display Problems in SeisWorks
Landmark
Troubleshooting Computed Contours

Problem Contours appear inside the fault polygons. Possible Solutions Use the Edit Polygons option to delete the points inside the polygons. If the contours are gridded, check the parameters you set in Map It. If you selected Do not use polygons, recalculate the gridding surface using the Use existing faults option. No annotation appears on the contours. Check the following in the Computed Contours Parameters dialog box (Contours Parameters Computed): Computed Contour Annotation is turned on. The text size is big enough. The text size is not too big. The annotation interval coincides with the times contours are drawn.
Troubleshooting Your Well Display

Frequently problems encountered while displaying wells are related to your parameter settings or your time-depth tables. Use the following table to check that you have set the well display parameters properly for the type of data you want to view. Problems with Well Display
Problem Wells do not appear on the Seismic View. Possible Solutions Reset the Criterion Distance option in the Seismic Well Parameters dialog box to a larger value. Check that the missing wells have been selected for display and that Generate well list for each new section is properly set. Check that the missing wells have time-depth tables assigned to them. Check that a measured total depth has been specified in the Well Data Manager utility. Check that position logs exist for the missing wells. Use the Well Data Export utility and attempt to export the wells position log. If the exported file is empty, the well has no position log. Check that the wells x,y coordinates are specified in the same units of measurement as the project. Use the Well Data Manager.
R2003.12.0.1Troubleshooting Seismic Display Problems: Other Display Problems in SeisWorks
61
Landmark
Problems with Well Display

Problem Too many wells are posted. Possible Solutions Reset the Criterion Distance option in the Seismic Well Parameters dialog box to a smaller value. Remove the wells that you do not want to be displayed from the active wells list. Set the Well Display Mode option in the Seismic Well Parameters dialog box to Part. Use the Show Location option to identify the portions of wells that now appear in the Seismic View. The curves that you expect to be displayed do not appear. Check that the Display Curve option in the Seismic Well Parameters dialog box has been set to Amplitude Log. Check that the curve has been selected for display. Reset the Track Width option in the Seismic Well Parameters dialog box to a higher value. Curves are overposted. Change the placement of the curves so that they are evenly distributed on the left and right sides of the well borehole. Check that tops have been turned on in the Contents dialog box and that the tops to be displayed have been selected using the Tops option under Wells on the menu bar.
Tops are not displayed.
62
Troubleshooting Seismic Display Problems: Other Display Problems in SeisWorks
Landmark

This chapter explains how to troubleshoot errors in the OpenWorks system and provides some recommended courses of action.

This chapter contains the following sections: Checking OpenWorks System Processes on page 64. This section describes the system processes that must be running for your OpenWorks system to function properly and contains procedures for starting and stopping these processes. Troubleshooting System Problems on page 68. This section contains solutions to a few common Landmark system problems.
R2003.12.0.1
Troubleshooting System Problems: Whats in this Chapter
63
Landmark
Checking OpenWorks System Processes

OpenWorks uses the following system processes which may be running on the workstation. All of these processes are required. OraclegRVhz oracle pd Oracle Server. The oracle server processes must be running at all times on the workstation. Pointing Dispatcher. Handles data communication between OpenWorks applications. Is started dynamically for each OpenWorks session. Network Services for OpenWorks applications. License Manager Daemon. This only runs on the machine which is the LAM manager. Typically started at boot time. License Server Process. This only runs on the machine which is the LAM manager. Typically started at boot time.
NetD lmgrd
licsrv
To check if OpenWorks processes are running, use the ps command with the -l option. For example:
ps -efl
(IBM, Solaris, or SGI)
To check on Oracle processes, use the su command to switch to the Oracle user account, then use the ps command. For example:
su - oracle ps -l
To check on a specific process, use the grep option with the name of the process or a fragment of the process name. For example:
ps -efl | grep ora
Starting/Stopping System Processes

Occasionally, you may want to start or stop various system processes. The following utilities are provided to help you. Starting/Stopping the Pointing Dispatcher The Pointing Dispatcher (pd) is started automatically through the Pointing Dispatcher Executor (PdEx) daemon when Dynamic PD is
64 Troubleshooting System Problems: Checking OpenWorks System Processes R2003.12.0.1
Landmark
turned on, which is the OpenWorks default setting. The Pointing Dispatcher should be stopped only if you have a dual environment running multiple releases of OpenWorks simultaneously. If you need to run the stop_pd script, refer to Configuring the Pointing Dispatcher in the manual OpenWorks System Administration: Managing the System. Starting Oracle If you stop Oracle and do not reboot, you must restart Oracle before continuing to use OpenWorks. To restart Oracle: 1. Use the su command to switch to the Oracle user account. For example:
su - oracle
2.
Restart the database server by entering the following command:

dbstart
3.
Start the Listener process by entering the following command:

lsnrctl start
Stopping Oracle Oracle keeps the most recent database changes in a cache. The contents of this cache may be lost if you reboot the system without stopping Oracle. Consequently, you should always stop Oracle first before rebooting the system. To stop Oracle: 1. Use the su command to switch to the Oracle user account. For example:
su - oracle
2.
Shutdown the database server by entering the following command:

dbshut
3.
Stop the Listener process by entering the following command:
R2003.12.0.1
Troubleshooting System Problems: Checking OpenWorks System Processes
65
OpenWorks Troubleshooting Guide lsnrctl stop Stopping and Restarting Oracle from Server Manager
Landmark
Both dbshut and lsnrctl work only if the letter Y appears at the end of the configuration setting in the file /etc/oratab. If these processes do not work, you can control the database server from inside the Server Manager utility using the appropriate commands. See the Oracle Server Manager Users Guide for more details.
Starting the LAM Manager To start the LAM manger, run the following script:
su - root setenv OWHOME OpenWorks_home_directory $OWHOME/lam/bin/startlmgrd
This should only be run on the machine which is the LAM manager. Stopping the LAM Manager To stop the LAM manager, run the following script:
su - root setenv OWHOME OpenWorks_home_directory $OWHOME/lam/bin/stoplmgrd
This should only be run on the machine which is the LAM manager.
Processes Initiated on Startup

When you start OpenWorks in a non-CDE environment using the startserver command, the following processes are started: X, mwm, a resource monitor (such as xosview, sdtperfmeter, or gr_osview), and launcher. When you start OpenWorks using the startow command in an X window, the following launcher process is started.
66
R2003.12.0.1
Landmark
The processes have the following dependencies: pd launcher resource monitor (such as xosview, sdtperfmeter, or gr_osview) mwm Requires NetD to be running; NetD spawns PdEx, which starts pd. Requires X to be running. Requires X to be running.
Requires X to be running, in a non-CDE environment.
Modifications to System Files

Some system files were modified during the OpenWorks installation. If there are problems, check to make sure that the correct modifications are present in the system files. The script $OWHOME/bin/rc.ow is the shell script that starts most required processes when the workstation boots. The script rc.ow is called at boot time by the system file /etc/ inittab (IBM) or /etc/rc2.d (SGI and Solaris). The rc.ow start-up call can be added to the system file when OpenWorks is initially installed. Appropriate messages are displayed at the end of the boot stream if these files are set up properly. For example:
Starting Landmark License Server (LAM)...
NOTE: $OWHOME is an environment variable defined in rc.ow. This variable is also defined in .lgcprofile or .lgclogin, where it should be the same as in rc.ow.
R2003.12.0.1
67
Landmark

The following pages contain guidelines for troubleshooting various system problems you may encounter while running OpenWorks.
Troubleshooting X
Symptoms: No gray screen. X errors issued to console shell. Solaris Workstations 1. Echo the value of the environmental variable $OPENWINHOME. This specifies where X has been loaded (echo $OPENWINHOME). Verify that files exist in that directory. Compare the file listing with a machine that is operating correctly. Solution: If there are missing files, the best solution is to reload the OpenWindows software from the OpenWorks release media. Refer to the Installing OpenWindows booklet. Sun, Silicon Graphics, and IBM Workstations Check to see that all entries in the $HOME/.xinitrc file are valid.
2.
Problems Starting SeisWorks

Below are solutions to some problems you might encounter in starting SeisWorks. /tmp Directory Full Several files are created in the /tmp directory as you run SeisWorks. If these files become corrupted and are not deleted when you reboot, you may have problems when you next attempt to open SeisWorks. To fix this problem, look for the files in /tmp, delete them, exit SeisWorks, and then start SeisWorks again.
68
Troubleshooting System Problems: Troubleshooting System Problems
R2003.12.0.1
Landmark
You can safely delete any of the following files. .dirdat .fs.lst .plist.tmp swild.ctr upd.prj *zycor.log (Export to Z-MAP Plus log) sys Directory Full During an interpretative session, SeisWorks creates certain temporary files and writes them to the project sys directory. Under normal circumstances, these files are cleared when you exit SeisWorks. If they are not deleted, you may find your sys directory becoming full. To remedy the situation, you can remove any of the following file types. hzbf.w# v<host_ID> <host_ID>.w3s tmp.* horizon buffers map buffer files temporary session files Z-MAP Plus sorting files
R2003.12.0.1
69
Landmark
70
R2003.12.0.1
Landmark

Introduction
This chapter contains information to help you locate and resolve problems with the Oracle database. Use this chapter to verify that Oracle has been installed correctly and has been configured to interact with the OpenWorks software. If you install Oracle using the Landmark Oracle install procedure, the procedure automatically configures Oracle to run with OpenWorks. However, if your site already has Oracle installed, or you are going to install Oracle directly from Oracle-supplied media, you must verify that your installation meets Landmark specifications.

This chapter contains the following sections: Before Using These Procedures on page 72. This section describes important information you should have before troubleshooting Oracle. Documenting and Reading Error Messages on page 73. This section discusses the importance of recording Oracle messages for use in troubleshooting. OpenWorks Requirements for Oracle on page 73. This section describes the settings and parameter values required by OpenWorks for Oracle installations. The Environment Status Tool and Oracle on page 77. This section discusses the error messages that could appear when using the Environment Status Tool to examine Oracle status. Using Server Manager to Query the Oracle Database on page 80. This section discusses the error messages that could appear when using the Environment Status Tool to examine Oracle status.
Troubleshooting Oracle Problems: Introduction 71
R2003.12.0.1
Landmark
Using Server Manager to Query the Oracle Database on page 80. This section contains the procedure for using Server Manager, a tool provided by Oracle for querying the database. Oracle in a Networked Environment on page 82. This section discusses important factors to consider when troubleshooting Oracle in a networked environment. Troubleshooting Oracle Problems on page 85. This sections describes steps you can take to troubleshoot common problems with Oracle.
Before Using These Procedures

The methods described in this chapter require database and system administration knowledge and skills. The instructions in this chapter assume that OpenWorks has been installed successfully. Before reading the chapter, you should be familiar with the following environmental variables OWHOME the location where the OpenWorks software is installed ORACLE_HOME the location where the Oracle software is installed ORACLE_SID the Server ID of the Oracle database instance
Refer to the OpenWorks System Administration manual set for a description of these terms as well as for a complete description of the OpenWorks environment. In addition, you should be familiar with the OW_ADMINISTRATOR role that provides additional security for OpenWorks projects. For a complete description of this role and the OpenWorks 2003 security model, see the OpenWorks Project Management manual.
72
Troubleshooting Oracle Problems: Before Using These Procedures
R2003.12.0.1
Landmark
Documenting and Reading Error Messages

When you encounter a problem, always document the error immediately. Whether it is an Oracle or application error, you can help by maintaining a log of the errors and the subsequent solutions. Even if you need to get technical support, you will have the problem well documented in a central log file for faxing or review. Error messages prefixed by ORA come from the Oracle database directly or through the application system. You have a simple facility available that can help identify the type of error. Enter the oerr command with the message number, as follows. For example, if the message number is 1234, you would enter:
oerr ORA 1234
The complete message is displayed below the command line for reference. This rarely provides a complete answer or solution but can provide quick hints to solving the problem. If you need more help, you can check your Oracle documentation for documented error messages, or call for help. If you call, be prepared to explain the events leading up to the problem. You may also want to check your log file to find any previous errors that may have led to your current problems.
OpenWorks Requirements for Oracle

OpenWorks 2003.3.0 requires Oracle 8.1.7.2, the 8.1.7.7 patch, and Net8 Configuration Assistant. The Oracle instance must meet with Landmark specifications for OpenWorks to interact successfully. If you install Oracle using the procedures described in the OpenWorks Installation Procedures document, including using the pre-Oracle process, all the parameter settings described in this section should already have been configured to interact with Landmark applications. If Landmark media is not the source of your Oracle database, please follow the recommendations in this section.
R2003.12.0.1 Troubleshooting Oracle Problems: Documenting and Reading Error Messages
73
Landmark
Recommended Settings
The table below shows,recommended resource settings.
Resource maxinstances maxlogfiles maxdatafiles maxlogmembers 1 40 254 5 Recommended
Recommended Datafile Sizes

Default datafile sizes provided by Oracle are inadequate for Landmark applications. The required datafile sizes are as follows:
Tablespace Name System Tablespace First Redo Log Files Second Redo Log Files Third Redo Log Files Rollback Segment Temporary Tablespace Users Tablespace Tools Tablespace Default Data File Namea sysowminnie.dbf logg1m1owminnie.dbf logg1m2owminnie.dbf logg2m1owminnie.dbf logg2m2owminnie.dbf logg3m1owminnie.dbf logg3m2owminnie.dbf rbsowminnie.dbf tempowminnie.dbf usrowminnie.dbf toolowminnie.dbf Landmark Default Size 600Mb 8Mb 8Mb 8Mb 8Mb 8Mb 8Mb 200Mb 100Mb 10Mb 15Mb
a. Oracle appends the ORACLE_SID to the filename. In the example, the ORACLE_SID is owminnie, where minnie is the server name.
For safety purposes Landmark strongly recommends mirroring Oracle Log files on separate disks. However, not having mirrored Log files will not affect the functioning of the Landmark applications.
74
Troubleshooting Oracle Problems: OpenWorks Requirements for Oracle
R2003.12.0.1
Landmark
Items Affecting Size Requirements The sizes shown above for system and rollback tablespaces may be insufficient if your site experiences any of the following conditions:
System Tablespace
Each OpenWorks project will take from 3 to 5 Megabytes of space in the system tablespace.
Rollback Tablespace
You may find that you wish to increase the size of your rollback tablespace if you encounter problems in doing the following: Creating large grids or pointsets in Z-MAP Plus or StratWorks. Working with very finely sampled log curve data in PetroWorks. Doing project backups while users are working in the very large projects. Doing backups for projects that have a very large number of wells (30,000 or more).
Database Block Size

Landmark recommends a default database block size of 8 Kilobytes. Oracle sets a default block size of 2 Kilobytes. Set the parameter in the instance configuration file config.ora to the following.
db_block_size = 8192
Oracle Parameters
Landmark applications have a few requirements about values of certain Oracle parameters. The following lines must appear in the instance initialization file, commonly known as the init{ORACLE__SID}.ora file. The db_files and max_enabled_roles parameters can have the given values or larger values.
compatible=8.1.7.1 os_authent_prefix="" remote_os_authent=true #NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS" db_files=254 max_enabled_roles=48 shared_pool_size=9000000 db_block_buffers=3200
R2003.12.0.1
75
Landmark
The following lines are recommended for performance reasons (the job_queue items are required for OpenExplorer Advanced Project Management):
pre_page_sga = true ccf_io_size = 131072 sort_area_size = 524288 #small_table_threshold = 20 open_cursors = 400 log_buffer = 1048576 max_dump_file_size=10240 dml_locks=500 job_queue_processes=2 job_queue_interval=60
Applying the Changes

After making the changes described above, you must shut down the database and restart it for the changes to take effect. After the Oracle instance has been restarted, please ensure that the OpenWorks-supplied database setup script is run by the Oracle DBA user. This script creates the tablespaces and Oracle users required by the OpenWorks database, Landmark specific views and other relevant steps. The listener process must be to running before the setup script is run. To start the listener process, as the Unix Oracle DBA user, type:
lsnrctl start
To run the database setup script, as Unix Oracle DBA user, type:
$OWHOME/install/owdbsetup
The Oracle role MONITORER must be defined in the Oracle instance. Please have your site DBA run the Oracle supplied script utlmontr.sql as the Oracle user SYS.
76
R2003.12.0.1
Landmark
The Environment Status Tool and Oracle

The OpenWorks Environment Status Tool allows you to examine various components of the OpenWorks system, including the Oracle database. You may encounter error messages when you try to check the status of Oracle. Following are examples of error messages that might pop-up if the Status Tool encounters problems.
Cannot open the database instance configuration file

This error is indicated by the following message.
There are three possibilities, summarized in the message box and listed below. The Oracle instance is not running on the machine where the Environment Status Tool is being invoked. This can typically happen in a client-server environment where the user is running the Environment Status Tool on the Oracle client. The tool needs to run on the Oracle server. The Unix user running this tool is not a known user to the Oracle instance that is being queried. (The one that is defined by the ORACLE_SID environment variable.) OpenWorks provides a script that simplifies this process. To run the script, login to the Oracle DBA account on the machine where Oracle is running, and type:
$OWHOME/bin/orauser
Proceed to add the current Unix user as an externally identified Oracle user. Selecting all the defaults provided by the script will do the necessary steps.
R2003.12.0.1 Troubleshooting Oracle Problems: The Environment Status Tool and Oracle 77
Landmark
This process is typically done when a Unix user is created by the lgcuser script provided by OpenWorks to add a new user or update an existing user. The instance configuration file, typically called $ORACLE_HOME/dbs/config.ora should be readable by all. Some Oracle installations make this file read protected. The Environment Status Tool requires this file to be readable by the Unix user running the tool.
Could not find Oracle Project Locations If the Oracle database can not find your OpenWorks project directories, the following message appears.
OpenWorks requires project locations to be known to the Oracle database. Project locations are directories where the OpenWorks software will create database files associated with OpenWorks projects. These locations are added when the script dboradir is run. If Oracle has been installed using the Landmark-supplied owinstall format, this will automatically be done for you. Otherwise the Landmark-supplied script owdbsetup needs to be run on the machine where the Oracle database is installed by the Unix Oracle DBA user. If no project directory locations are specified, the default location of $ORACLE_HOME/dbs is assumed. Could not find the Oracle Database Log Files If the Oracle role MONITORER has not been created, the following message appears.
78
Troubleshooting Oracle Problems: The Environment Status Tool and Oracle
R2003.12.0.1
Landmark
For the Environment Status Tool to correctly diagnose the Oracle configuration, the user running the tool should have the Role MONITORER granted. Once again if the installation is a standard Landmark installation, this is already done for you. If this is not a standard Landmark installation, the role MONITORER first needs to be created for this particular Oracle installation. Please have your Site DBA run the Oracle-supplied script utlmontr.sql as the Oracle user SYS. Once that is done have the DBA assign the role to the Unix user running the Environment Status Tool. The utlmontr.sql script is found in the $ORACLE_HOME/rdbms/admin directory.
R2003.12.0.1
Troubleshooting Oracle Problems: The Environment Status Tool and Oracle
79
Landmark
Using Server Manager to Query the Oracle Database

Server Manager is a tool provided by Oracle to query the database instance. This section describes how to use Server Manager to query the database for certain information that you need to know. OpenWorks requires three OpenWorks specific internal Oracle users to be created: owsys owsysp lmsys
The users owsys and owsysp have tablespaces owsys and owsysp associated with them. Use the following procedures to check whether the users and tablespaces exist and are set up correctly. Login as the Unix Oracle DBA user, then type the following:
svrmgrl
You will be put in the Server Manager environment. Type:

connect internal
You are now connected as a privileged Oracle user called internal. Next, query the Oracle instance:
select username, default_tablespace, temporary_tablespace from dba_users;
You should see a listing similar to the following:

USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLE --------------------------------------------------SYS SYSTEM TEMP SYSTEM TOOLS TEMP OWSYS OWSYS TEMP OWSYSP OSWYWP TEMP LMSYS SYSTEM TEMP VISPI USERS TEMP 6 rows selected.
The users SYS and SYSTEM are present in all Oracle instances. Notice that the users OWSYS and OWSYSP are associated with the default tablespaces OWSYS and OWSYSP. The preceding query verifies that
80
Troubleshooting Oracle Problems: Using Server Manager to Query the Oracle Database
Landmark
the relevant users exist. If these users do not exist, you must run the OpenWorks owdbsetup script as the Unix Oracle DBA user. The next query verifies the existence of the tablespaces OWSYS and OWSYSP. Type this command:
select tablespace_name, status, file_name from dba_data_files order by tablespace_name;
This query lists all the tablespaces known to the current Oracle instance, the status of these tablespaces, and the data files associated with each tablespace. Your screen listing should be similar to the following output:
TABLESPACE STATUS FILE_NAME -----------------------------------------------------OWSYS AVAILABLE /pa/ow/oracle/dbs/owsys_tbs.dbf OWSYSP AVAILABLE /pa/ow/oracle/dbs/owsysp_tbs.dbf RBS AVAILABLE /pa/ow/oracle/dbs/rbsownova.dbf SYSTEM AVAILABLE /pa/ow/oracle/dbs/sysownova.dbf TEMP AVAILABLE /pa/ow/oracle/dbs/tempownova.dbf TOOLS AVAILABLE /pa/ow/oracle/dbs/toolownova.dbf USERS AVAILABLE /pa/ow/oracle/dbs/usrownova.dbf 7 rows selected.
The preceding list shows that the tablespaces OWSYS and OWSYSP exist and are available. It also verifies that the data file associated with the tablespace physically exists on the system. If you find that the OWSYS and OWSYSP tablespaces do not exist, run the OpenWorks script owdbsetup as the Unix Oracle DBA user. If the tablespaces OWSYS and OWSYSP exist but their status is OFFLINE or INVALID, please have the site DBA make them AVAILABLE or call your Landmark representative for assistance. To exit from Server Manager, type:
exit;
More on Oracle users in OpenWorks Project Management manual In addition to the basic roles described here, the OW_ADMINISTRATOR role that provides additional security for OpenWorks projects. For a complete description of this role and the OpenWorks 2003 security model, see the OpenWorks Project Management manual, OpenWorks Security Model chapter.
R2003.12.0.1Troubleshooting Oracle Problems: Using Server Manager to Query the Oracle Database 81
Landmark
Oracle in a Networked Environment

Oracle in a networked environment could imply different configurations. peer-to-peer configuration. This means that two or more Oracle instances, on separate or same machines, each having stand-alone capabilities, are set up to communicate with each other. client-server configuration. This typically means a machine is NFS mounting Oracle binaries from an NFS server, and accessing an instance on a remote machine through SQL*Net. An Oracle instance is not present on the client machine.
This section provides a brief description of the most common pitfalls and problems encountered in a networked environment. Troubleshooting client server, and exploring SQL*Net in detail is beyond the scope of this manual. Please refer to the SQL*Net manual for further information. The files listener.ora and tnsnames.ora are important for a networked Oracle environment. These files can be found in the directory: defined by the environment variable $TNS_ADMIN $ORACLE_HOME/network/admin if $TNS_ADMIN is not set /etc if not found in the above directories
The listener.ora file

The listener process is a daemon process that runs on a machine which wants to accept connections over the network from remote machines. There is just one listener process running on a machine, even if there are multiple Oracle instances on the machine. The listener process has a configuration file associated with it. The configuration file, called the listener.ora file, has information about all the instances on the local machine that are willing to accept networked connections, and are willing to be serviced by the listener process. The following is a sample listener.ora file.
82
Troubleshooting Oracle Problems: Oracle in a Networked Environment
R2003.12.0.1
Landmark LISTENER= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=tcp) (PORT=1521) (HOST=minnie) ) (ADDRESS= (PROTOCOL=IPC) (KEY=owminnie) ) )
SID_LIST_LISTENER= (SID_DESC= (SID_NAME=owminnie) (ORACLE_HOME=/export/home4/test/oracle) )
The sample file services one instance, owminnie, on the host machine minnie. It accepts TCP and IPC connections for the instance. The listener process listens on the reserved port number 1521 for incoming TCP connections. The ORACLE_HOME variable associated with the instance owminnie is /export/home4/test/oracle. The installation process creates a listener.ora file for the instance you have installed.
The tnsnames.ora file

The tnsnames.ora file is a list of all the instances on the network that are available to the current instance, including itself. The remote instances still reserve the right to restrict the current instance from connecting. A sample tnsnames.ora file is as follows:
owminnie= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=minnie) (PORT=1521) ) (CONNECT_DATA= (SID=owminnie) ) )
R2003.12.0.1
83
OpenWorks Troubleshooting Guide owrocky= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=rocky) (PORT=1521) ) (CONNECT_DATA= (SID=owrocky) ) )
Landmark
With this tnsnames.ora the instance can connect to the instance owminnie, on the host minnie via the TCP protocol. It can also connect to the instance owrocky on the host rocky via the TCP protocol. It is assumed that the listener process is running on both those hosts and it listens on port 1521. The tnsnames.ora file that is shipped with Oracle must be edited to work properly in an OpenWorks environment. For example, formatting issues and the use of lower case letters in the file must be corrected so that OpenWorks daemons will run. Edit $ORACLE_HOME/network/admin/tnsnames.ora and make sure that the following words are all upper case: DESCRIPTION, ADDRESS, PROTOCOL, HOST, PORT, CONNECT_DATA, SID To troubleshoot problems with tnsnames.ora, run
$OWHOME/bin/owlistsids $ORACLE_HOME/network/admin/tnsnames.ora
Two values should be returned; the first is the ORACLE_SID, and the second is the host name. For example,
owminnie minnie
84
R2003.12.0.1
Landmark

This section describes the preliminary steps to take in troubleshooting the Oracle database system. For more advanced troubleshooting techniques, refer to the appropriate section in the chapter Oracle Troubleshooting in the Oracle Database Administrators Guide. If the problem cannot be corrected using the techniques explained in any of these sources, contact to your Landmark Technical Representative.
Database Processes May Not Be Running

If you suspect a problem with the Oracle database, you should check to make sure all processes are running. Oracle has six essential database processes that must be running before you can access a database.
Process Dispatcher Name ora_dnnn_<SID> Purpose An optional background process responsible for routing requests from connected user processes to an available shared server process and returning the responses back to the appropriate user process. Performs all writes from the database cache in memory to the database files on disk. Writes only occur when more data needs to be read into the SGA and there is too little free space in the database buffers. Performs all writes from the redo log buffers in memory to the log files on disk. As transactions commit, this process writes redo log entries into an on-line redo log file. Watches the processes accessing Oracle and makes sure that processes exit properly. Cleans up resources of processes that fail. Ensures the database is ready for use when Oracle is started. It performs instance recovery. Helps recover from failed distributed transactions by rolling back the system (i.e., restoring the database to the condition it was in before the transaction occurred). 85
Database Writer
ora_dbwr_<SID>
Log Writer
ora_lgwr_<SID>
Process Monitor
ora_pmon_<SID>
System Monitor Recovery Process
ora_smon_<SID>
ora_reco_<SID>
R2003.12.0.1
Troubleshooting Oracle Problems: Troubleshooting Oracle Problems
Landmark
These processes are started when the workstation is booted and should remain running until the workstation is halted. Use the following command to verify that Oracle processes are running:
ps -efl | grep ora
This command should display the following entries. (If you are running a client-only workstation, there are no Oracle processes running on your workstation. Be sure Oracle is running on your server.)
409 410 412 413 414 415 416 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.5 2.0 1.5 0.0 0.0 0.0 0.0 228 1768 200 2372 200 1776 468 0 220 0 200 136 272 0 S S S IW IW IW IW 14:05 14:05 14:05 14:05 14:05 14:05 14:05 0:00 0:00 0:00 0:03 0:00 0:00 0:00 ora_pmon_ownova ora_dbwr_ownova ora_lgwr_ownova ora_smon_ownova ora_reco_ownova ora_s000_ownova ora_d000_ownova
If some of the processes are not running, restart the Oracle database server. To restart Oracle, exit from all application programs and execute the following commands:
su - oracle dbstart lsnrctl start
If an error occurs during startup, it is displayed on the screen and logged in the file $ORACLE_HOME/rdbms/log/alert_sid.log. If necessary, refer to the Oracle documentation for more detailed descriptions of log files and error messages. The error message should indicate which processes did not start.
Unable to Connect to a Local Database

Connecting to a local database requires that the Oracle processes are running (refer to the section Database Processes May Not Be Running on page 85 for more information) and that you have authorization to access the database. The utility program orauser lets you provide user access to Oracle. For more details see the Manging the System manual and the OpenWorks installation procedures.
Unable to Connect to a Remote Database

Connecting to a remote database requires that the Oracle processes are running on the local and the remote workstation and that you have permission to access the remote database. For information on database processes, see Database Processes May Not Be Running on page 85.
86
R2003.12.0.1
Landmark
For more details see the Manging the System manual and the OpenWorks installation procedures.
Unable to Halt the Oracle Processes

The Oracle command dbshut is used to halt all Oracle processes before rebooting the workstation. You must exit from all application programs before running this command. The dbshut command will not shutdown the database if applications are still connected.
Cannot Shut Down Database

In many cases the shutdown normal and even the shutdown immediate commands will hang up the system. At this point you have two options. Identify the processes connected to the system that are causing the hangup. Break or kill the shutdown process.
Identifying the current processes will have to be done through Server Manager, since no further standard connection can occur during a shutdown. Breaking the process can work, but usually this results in the need for a shutdown abort shortly after. The key is to make sure all connections are cleared before shutdown. If you do not have that luxury, a shutdown immediate is worth trying. As a last resort, the abort command may be unavoidable. You may want to review the $ORACLE_HOME/rdbms/log/alter*.log files and any *_PID.trc files to see if information has been written recently. Background processes can die or fail and the database writes these results to the log and trace files. If these trace files do not provide immediate clues, a shutdown abort must be performed. You have the option of calling for support prior to shutting down, but it depends on your immediate needs. Once the shutdown abort completes, immediately try to restart the system before doing any maintenance work, unless you know it is absolutely necessary. If maintenance was scheduled, you can start with more confidence after a clean shutdown.
Cannot Start Database

Usually, you only have to start the database if you have been forced to shut down or if the system requires maintenance. This introduces a
R2003.12.0.1 Troubleshooting Oracle Problems: Troubleshooting Oracle Problems 87
Landmark
wide variety of problems of different severity. Once again the key is reviewing the trace and log files to see if anything out of the ordinary has occurred during the last shutdown or during system maintenance. A message such as:
ORA-01157 cannot identify file id - file not found
implies that the files listed in the control file cannot be accessed by the database during startup. If you do not have the list of all files located within the database, you should start Server Manager using svrmgrl and issue the connect internal command. Then spool the results from querying v$datafile and v$logfile with the database startup mount command completed. These internal tables give you a full listing of the files used by the control file (except for the control files themselves, which are listed in the config.ora file). Files Moved or Changed A file may have been moved, renamed, or deleted during standard operation or during shutdown. Most of these cases can be corrected, but the file in question must be identified. Make sure that all of these files exist. If they do not, you must carefully evaluate what has happened to the file in question. This is critical to your ability to recover your current database without being trapped into recovering from the last weeks backup. If any of the files were moved during the operation of the database, you have an even chance to recover the current system without corruption. If they were moved while the database was being shutdown, recovery is almost certain. Recovery Strategies There are two key factors to recovering your database in these cases. Is your system in archive mode? Is it archiving all online redo logs? Has the system been changed since the file was moved?
If the first case applies, this problem is beyond the scope of the current troubleshooting procedures, but can be handled using Oracle techniques documented in the Oracle8 Server Administrators Guide.
88
R2003.12.0.1
Landmark
If the second case applies, consider your situation carefully before proceeding: 1. Try to copy the most recent version of the datafile to the location required. If the startup fails again, decide if the data is required to continue all other operations. Unfortunately if it is the SYSTEM or RBS tablespace data files, you must return to your cold backup. If any other datafile is in question you can simply drop the datafile before the database starts up. If you choose to drop the object before the database starts up, you are committing to the current database and leaving all data and work associated with that file behind. Once the database is running, you can then re-create the file if needed. The statements required to perform this operation are clearly documented in the Understanding Oracle Guide.
2.
3.
Object or Data Lost

Typically, unless the environment has very tight security, a user will drop a table or remove all the rows from it. In many cases this situation is unrecoverable. However, if the object was from the project tablespace, you can recover the tablespace objects and data using the recover project function in the application. An export file is the only true means for recovering lost data or a dropped table.
WARNING: Beware of inconsistent data Be aware that the export file may contain data that is inconsistent with the current data in the project. Recovering just the one object lost from that export file is possible but should be done with the aid of Technical Support to determine the effects of that approach.
Database Resource Limits

While running an application, your process may pause, hang or fail with or without error messages. In most cases, the failure of your process has resulted from a connection failure mentioned above.
R2003.12.0.1
89
Landmark
However some other process limits may have caused the problem. You may see error messages such as:
ORA-01547 failed to allocate extent of size num in tablespace name ORA-01562 failed to extend rollback segment (ID=num) ORA-01631 max # of extents (num) reached in table name
These types of errors all stem from the resource availability within the Oracle database. In most cases where resources are concerned, the users process will fail and the error message will be returned. At this stage, you must assume that if you try the same process the same results will occur. Document the error and then try the same process if the event was not very time-consuming. If you receive a consistent result you should report the object in question to technical support for specific instructions on correcting the resources to allow completion of the transaction.
Database Connection Problems

Your application connects to the system frequently when working with projects or application data. During this process you can get any of the following errors:
ORA-01017: ORA-01034: ORA-12154: ORA-010145: Invalid username/password. Oracle not available. TNS Unable to connect to destination. User lacks create session privilege, logon denied.
There are many reasons these errors can occur but the checklist below is the quickest path to determining the problem. With each item in the list there is a brief description of the tasks required to complete the checklist. If you need more detail please refer to the Open Works System Administration Guide. Check your environment variables. Oracle software and your access to it depend heavily on the variables ORACLE_SID, ORACLE_HOME, and LD_LIBRARY_PATH to locate the software and libraries required for Oracle products and applications. There are others for your particular application but without these properly set, you cannot use the database.
90
R2003.12.0.1
Landmark
Check for database activity. Log on using the Oracle account and use the following command to check for background processes.
ps -al | grep ora
You can confirm by logging into SQL*Plus directly using the following command:
sqlplus system/password
If the database is not running, review the log files in $ORACLE_HOME/rdbms/log/alter*.log to determine if there were any problems with the database. Restart the system using the following commands to initialize the Oracle background processes.
svrmgrl connect internal startup
Check for network processes. Log on to your workstation as oracle and verify that the Listener process for SQL*Net is active. This is an Oracle background process that connects users to the database. You can use the following command to confirm the process is active.
lsnrctl stat
You can also confirm by connecting directly to the database. For example:
sqlplus system/password@ownova
If the network listener is not active, use the following command to activate the process.
lsnrctl start
OraclegCP
Check Oracle privileges for the user account. Each user account must have sufficient privileges to connect to and access the database. To confirm this, use the following command:
sqlplus system/password
then review the information in the DBA_ROLE_PRIVS table to determine that the user has connect and resource privileges. If not you can alter the user by entering the following SQL command:
R2003.12.0.1
91
OpenWorks Troubleshooting Guide grant rolename to username;
Landmark
92
R2003.12.0.1
Landmark
Common Error Messages

Introduction
Error messages are an important source of information to help you learn the cause of a problem. Error messages could appear in any of the following locations: popup dialog boxes the console window the SeisWorks Main Menu window an error log file (s3d.err for example) in $HOME/run the xterm window from which you started an application
To insure that you see relevant error messages, keep both the console window and the main menu of the application you are using open and visible as you work.

This chapter contains the following sections: Setting the Error Level on page 94. This section describes the OpenWorks error reporting system, which you can use to determine the causes of system problems. Using the OpenWorks Error Logger on page 99. This section contains the procedure for setting the error level using the OpenWorks Error Logger utility. Common OpenWorks Error Messages on page 100. This section describes typical OpenWorks error message and their solutions. Common SeisWorks Error Messages on page 103. This section describes typical SeisWorks error messages and their solutions.
OpenWorks v{z^
OpenWorks^8 SQvQehH
SeisWorks^8 SQvQehH
R2003.12.0.1
Common Error Messages: Introduction
93
Landmark
Setting the Error Level

The error level determines how severe a problem must be before you get an error message. The lower the error level is, the more frequently you will receive error messages. Error Level
4 3 2 1 0
Types of Messages
No errors reported for OpenWorks programs. Severe or fatal errors. Potentially serious errors. Warnings. Full history of all OpenWorks routines called.
The default setting is Error Level 3. Error Level 0 may provide too much information to be helpful. For example, if you are having problems with SeisWorks/3D, you might lower the error level within an xterm window, start SeisWorks/ 3D from that window, and repeat the sequence of steps that caused the problem in your original session. This time, more detailed diagnostic information will be posted in the xterm window.
ERR_LEVEL controls error reporting. ERR_LEVEL is an environmental variable that controls the level of error reporting. It is typically set in the configuration file (lgcenv.cf) but could be set in the initialization file (.lgcprofile or .lgclogin). See the OpenWorks System Administration: Managing the System manual for information on locating and setting environmental variables.
Checking the Error Level

To determine the current error level, type
lgc_getenv ERR_LEVEL
94
Common Error Messages: Setting the Error Level
R2003.12.0.1
Landmark
Changing the Error Level

For most diagnostic purposes, an error level of 2 provides sufficient information. The required commands are slightly different if you are working in a Bourne shell or a C shell. The following examples show changing the error level to diagnose SeisWorks problems. In a Bourne Shell To change the error level to 2, type the following commands:
ERR_LEVEL=2 export ERR_LEVEL
Now start SeisWorks from that same shell by typing

s2d (to start SeisWorks/2D)
or
The Bourne shell posts detailed error messages as you work. In a C Shell To change the error level to 2, type
setenv ERR_LEVEL 2
Now start SeisWorks from that same shell by typing

or
The C shell posts detailed error messages as you work.
To Change the Error Level Globally The procedures outlined above for setting an error level within a Bourne or C shell affect only those applications started from that shell. Applications started from other windows or from the OpenWorks Command Menu will continue to use the error level defined in the configuration file (lgcenv.cf) or initialization file (.lgcprofile or .lgclogin). If you wish to change the error level setting for all applications, you must edit the file containing the ERR_LEVEL variable. See WHERE for instructions.
R2003.12.0.1
95
Landmark
Viewing the Error Messages

How you start the application influences where error messages are posted. For Applications Started from the Command Menu When you start Landmark applications from the OpenWorks Command Menu, error messages are written to the run directory. Typically run resides in your home directory. Each application has its own .err file in the run directory. To see the error messages for SeisWorks, perform the following steps: 1. Change to your home directory, then to the run directory by typing
cd cd run
2.
Display the SeisWorks error file by typing

more s2d.err (SeisWorks/2D)
or
more s3d.err (SeisWorks/3D)
3.
To display and continually update the error file as you work, type
tail -f s2d.err (SeisWorks/2D)
or
tail -f s3d.err (SeisWorks/3D)
The file is overwritten when you open a new SeisWorks session.
96
R2003.12.0.1
Landmark
For Applications Started from an xterm When you start a Landmark application by entering its startup command in an xterm window, error messages are automatically and continually posted in that window. You can direct those messages to a file. This frees the window for other uses and captures the messages so that you can review or print them. There are two alternatives for this method: directing error messages to a script file directing error messages to a text file
Directing Error Messages to a script File

This method records the error messages to a file you specify with the script command, as follows: 1. In an xterm window, set the error level to zero:
ERR_LEVEL=0 export ERR_LEVEL
(in a Bourne shell)
or
setenv ERR_LEVEL 0
(in a C shell)
2.
Enter the script command:

script <myerrorfile>
3.
Start your application in the same xterm using its executable name. You can find these names in the launcher.dat or swlauncher.dat file, for instance. Each executable command appears in the column after the applications name; use only the first word. For example:
or
4.
To view the resulting file, type

more <myerrorfile>
As the application runs, any errors display in the xterm and a copy is sent to the file. In addition, you can type annotations of your workflow in the xterm, and this is also saved. When you finish running the
R2003.12.0.1
97
Landmark
application, exit from the application menu. Then, in the xterm window type exit to exit from the script file.
Directing Error Messages to a Text File

This method, which is similar to the preceding one, also sends error messages to a file. This method, however, does not allow you to annotate your workflow in the file. To direct the messages to a text file, use one of the following commands, depending on the type of shell you are in: Bourne Shell:
s2d 1> <filename> 2>&1 (2D)
or
s3d 1> <filename> 2>&1 (3D)
C Shell:
s2d >& <filename> (2D)
or
s3d >& <filename> (3D)
To view the resulting file, type

more <filename>
98
R2003.12.0.1
Landmark
Using the OpenWorks Error Logger

OpenWorks Error Logger N:Y OpenWorks^u(z ^T StratWorksc ONNyn ~R+v{Oel0 OF[NN: SeisWorksn ~R+0 The OpenWorks Error Logger provides an easy way to set the error level for many OpenWorks utilities and for StratWorks. However, it does not set the error level for SeisWorks. To use the OpenWorks Error Logger, perform the following steps. 1. From the OpenWorks Command Menu, select System Error Logger. The following dialog box appears.
2.
Select the OpenWorks utility or application from the list on the left. Click on the radio button for the Error Level you wish to use while running this application. In the field labeled Error Log File, enter the full pathname of the file where you want the error messages placed. Select Controls Run to start the application.
3.
4.
5.
Error levels are same for the Error Logger and the keyboard. The error levels used by the OpenWorks Error Logger are identical to those you enter from the keyboard.
R2003.12.0.1
Common Error Messages: Using the OpenWorks Error Logger
99
Landmark
Common OpenWorks Error Messages

The following section describes some common OpenWorks error messages and their solutions.
The master database owsys could not be connected Error reading the OpenWorks system database (owsys)!
Cause: Oracle is not running.
Solution: Check that the Oracle server is running. If it is not, restart the server by logging into the Oracle server and issuing the following commands:
dbshut dbstart
Cause:
Your system is a client that is not mounted to the Oracle server.
Solution: In an xterm, check the OWSYSSID variable by typing:

echo $OWSYSSID
This variable identifies the host ID of the server where Oracle database is installed. Note that, by Landmark convention, the OWSYSSID specification often includes an ow prefix. For example, if OWSYSSID is specified as owjazzman, the actual host ID is jazzman. Use the df command to determine whether your system is mounted to the Oracle server. Cause: The OpenWorks variable OWSYSSID is not set correctly.
Solution: In an xterm, check the OWSYSSID variable by typing:

echo $OWSYSSID
If this variable is not set to the host ID of the system where Oracle is installed, use vi to edit the appropriate file. Prefix
100 Common Error Messages: Common OpenWorks Error Messages R2003.12.0.1
Landmark
the two letters ow to the hostname. Then exit from X, log out, and log back in. Cause: The OpenWorks variable ORACLE_HOME is not set correctly.
Solution: Check the ORACLE_HOME variable by typing

echo $ORACLE_HOME
in an xterm window or by checking the Environment Status Tool. If this variable is not set to the directory where the Oracle database has been installed, use vi to edit the appropriate Unix initialization file. Then exit from X, log out, and log back in.
Unable to connect to the default $ORACLE_SID database

Cause: You cannot reach the Oracle server because of a network problem.
Solution: Check with your system administrator to see if you have a network problem. Cause: Your ORACLE_SID variable is not set correctly.
Solution: Check the System Configuration panel of the Environment Status Tool to see if ORACLE_SID is set to the proper instance ID. (See Tools for Troubleshooting on page 17.) If ORACLE_SID is not set, set it in the appropriate Unix configuration file.
Cannot open the database instance configuration file

Cause: You are trying to use the Database Sanity Checker to query the database instance configuration file from a client.
Solution: The database instance configuration file cannot be queried from a client. If you want to check the setup of the Oracle server, you must do so from the server itself.
oracleg RVhnSNgRVhg,L0
R2003.12.0.1 Common Error Messages: Common OpenWorks Error Messages 101
Landmark
Cause:
Your ORACLE_SID is not set correctly.
Solution: Check the System Configuration panel of the Environment Status Tool to see if the ORACLE_SID is set to the proper Oracle server ID. If it is not, reset it in the appropriate Unix configuration file. (See Tools for Troubleshooting on page 17.) Cause: Your database instance configuration file does not have read permission. (Relevant only if your system is an Oracle server.)
Solution: Generally, the database instance configuration file is called $ORACLE_HOME/dbs/config.ora. This file should be readable by all. If the file does not currently have read permission, have your Oracle database administrator change it so that it does.
OpenWorks Database Project *nowell* Initialized

Cause: Your seismic project is not associated with an OpenWorks project.
Solution: Ensure that your seismic project is associated with an OpenWorks project. 1. In an xterm window, type plist. You receive a list of all currently available SeisWorks projects and their corresponding OpenWorks projects. This list duplicates the contents of the plist.dat file. 2. Confirm that an OpenWorks project is listed against your seismic project. 3. If plist does not show a project associated with your seismic project, use the Seismic Project Associate utility (available from the Seismic Project Managers Project menu) to associate an OpenWorks project with your seismic project. SeisWorks/2D users can find more information in the Master Projects and Working Projects chapters of the SeisWorks/2D Project Management manual. SeisWorks/3D users should refer to the 3D Projects chapter of SeisWorks/3D Project Management.
102 Common Error Messages: Common OpenWorks Error Messages R2003.12.0.1
Landmark
OpenWorks Troubleshooting Guide An OpenWorks project is always necessary. You cannot run SeisWorks without initializing an OpenWorks project. You must always associate an OpenWorks project with a SeisWorks project when you create the SeisWorks project.
OpenWorks]S:f/ elLSeisWorksv0W(R ^SeisWorks]S:e_{\ OpenWorks]S:NgN SeisWorks]S:vQsT0
OpenWorks Database Project <Project_Name>: Access Failed

Cause: OWSYSSID is not set correctly.
Solution: In an xterm, check the OWSYSSID variable by typing

echo $OWSYSSID
If this variable is not set to the host ID of the system where Oracle is installed, use vi to edit the appropriate file. Prefix the two letters ow to the hostname. Then exit from X, log out, and log back in.
You must be the Project Owner to Use this.

Cause: You do not have authorization to modify, delete, or back up the selected project.
Solution: Have a user with MANAGE authority and the OW_ADMINISTRATOR role grant confer the same authority and role to your account.
Common SeisWorks Error Messages

The following section describes some common SeisWorks error messages and their solutions.
Cannot open .sm files. Cannot continue. (SeisWorks/2D)

Cause: The working project has been modified without updating the seismic map (.sm) files.
Solution: Update the working project. 1. Exit SeisWorks.

update2d <projectname>
R2003.12.0.1 Common Error Messages: Common SeisWorks Error Messages 103
2. At system prompt, type
Landmark
3. Reopen SeisWorks.
Cannot set project or Cannot open project definition file

SeisWorks/2D Solutions Cause: The application cannot open the project definition file (.ps2) for some reason.
Solution: Check permissions on the project definition file (.ps2), and change them to read-write if necessary. Cause: The application cannot find your project sys directory, and the project definition file (.ps2) resides there.
Solution: Check that dir.dat has been defined correctly. The location of this file is defined by $OW_PMPATH, which is usually set to the directory $OWHOME/conf. However, if your system is running as a client or has been modified at your site. dir.dat may be in $OW_DDF. SeisWorks/3D Solutions Cause: The application cannot open the project definition file (.pds) for some reason.
Solution: Check permissions on the project definition file (.pds). Change them to read-write if necessary. Cause: The application cannot find your project sys directory, and the project definition file (.pds) resides there.
Solution: Check that dir.dat has been defined correctly. This file usually resides in the $OW_PMPATH which is often $OWHOME/conf. However, if your system is running as a client or has been customized, dir.dat may be defined by $OW_DDF. Common Solutions Cause: The application cannot open the project directories.
Solution: Check permissions on those directories. Change them to read-write-execute if necessary.
104
Common Error Messages: Common SeisWorks Error Messages
R2003.12.0.1
Landmark
Cause:
The environment is not properly defined.
Solution: Check that the environmental variable SEIS_DPATH is set. See VARIABLES for information on variables. Cause: You tried to open a session before selecting a project.
Solution: Select the project first, then open a new or existing session. Cause: Someone has deleted the selected project from your system.
Solution: Restore the project using the SeisWorks Backup/Restore utility, or copy the project directories from another system onto yours.
Error in survey parameters in .pdf and .hrz

Cause: The project as defined by master grid does not encompass the location or extent of your horizons.
Solution: Delete the horizon index file (.hrz) and recreate it using the HrzUtil utility. If this does not solve the problem, call Landmark Customer Support.
No fault segment/heave selected for assignment.

Cause: In trying to correlate faults, you selected a fault plane name without first selecting a fault segment or heave.
Solution: Select a fault segment or heave, then select the fault plane you want to assign it to.
.pd2 file not present (SeisWorks/2D)

Cause: You are trying to open a 3D project within SeisWorks/2D.
Solution: Exit SeisWorks/2D. Start SeisWorks/3D and choose the project again. Or, if you specified that project by mistake, start SeisWorks/2D and choose the correct project.
R2003.12.0.1
105
Landmark
Viewport Not Allocated

Cause: The SEIS_DPATH environmental variable has not been properly set.
Solution: Set the SEIS_DPATH environmental variable in lgcenv.cf to

$OWHOME/SeisUtils/dat
Give the absolute path for OWHOME. (Generally, lgcenv.cf is located in $OWHOME/conf.)
Virtual Graphics Error

Cause: This often happens when you add a disk and create a directory with root permissions.
Solution: To give all users full access to all project directories, perform the following steps: 1. To assume superuser status, type
su
2. Now, as root, type

chmod -R 777 /p?
The above instructions assume, of course, that all your project directories begin with the letter p (/pa, /pb, /pc, etc.). If this is not the case, use the appropriate combination of letters and wildcards to include all the project directories when you change the permissions.
106
R2003.12.0.1
Landmark
Index
C color bars problems getting two on a screen 59 Color Control option mode affects data display 59 Command Menu expanding to check processes 5 contest2d utility 52-53 contours, computed troubleshooting 60 D data access failure occurs 39 troubleshooting 26-42 data files cannot be found 36 data loading problems 54 records dropped due to errors 54 synthetics not in Seismic View 55 tops not appearing correctly in Seismic View 55 TVD for deviated wells too shallow 54 well symbols appear in 2D display but not in Map View 55 wells appear in 2D display but not in Map View 54
R2003.12.0.1
wells appear in Map View but not in Seismic View 55 wells appear in Seismic View, but not curves or tops 55 data type user not owner 40 dbshut 65 depth preference not set 39 dir.dat 48 .dirdat 69 disk space checking 11 display gaps/white spots on seismic line 58 no seismic display 58 snow/stripes on seismic display 58 E Environment Status Tool 18-19, 33, 38 ERR_LEVEL 38, 40, 94, 95 error level changing 95 setting 94 error log generating with contest2d 52-53
Index 107
Landmark
error messages 93-106 common messages in OpenWorks 100-103 common messages in SeisWorks 103-106 viewing 96 F files changing permission mode 44-47 checking continuity of line, horizon, & seismic files 52-53 paths for master project files, determining 52-53 .fs.lst 69 G
LGC_DEBUG using to troubleshoot SeisWorks problems 22-24 .lgclogin 67 .lgcprofile 67 License Manager Daemon 64 License Server Process 64 licsrv 64 Listener Port 34 listener.ora 82 lmgrd 64 LMSYS 80
gr_osview (IRIX resource monitor) 67 lsnrctl 66 grep 64 M H master projects horizon catalog 47 K mwm 67 killing & restarting X server 9 killing processes 8-9 L Network Services 64 LAM Manager 64 starting 66 stopping 66 launcher 67 $OPENWINHOME 68
108 Index R2003.12.0.1
checking with contest2d 52-53 size of, determining 52-53
N NetD 28, 64, 67
Network Services Daemon 28 O
Landmark
OpenWorks data access failure 39 data access problems 36-42 data type ownership 40 depth preference 39 environment variables 36 priority list 39 OpenWorks environment 27 checking with Environment Status Tool 19 OpenWorks Error Logger 99 OpenWorks project 26 OpenWorks system processes 5-9, 64-67 checking 5-9 checking running processes 5 initiated at startup 66 killing a process 8-9 runtime status box 5 starting/restarting processes 7-8 starting/stopping 64 Oracle accessing the database 29 database connection problems 90 database processes not running 85 database resource limits 89 default database block size 75 environment variables 35 error messages 73 in a networked environment 82-84 making changes effective 76 object or data lost 89 OpenWorks requirements 73-76 problems 85-92 recommended datafile sizes 74
R2003.12.0.1
recommended resource settings 74 required parameters 75 starting 65 starting the listener process 76 stopping 65 system process 64 troubleshooting 71-92 unable to connect to a local database 86 unable to halt processes 87 unable to shut down database 87 unable to start database 87 using Environment Status Tool 77-79 using Server Manager to query the database 80-81 Oracle instance 29 Oracle Server 64 ORACLE_HOME 31, 35 ORACLE_SID 31, 35 OW_ADMINISTRATOR 81 OW_DBTYPE 35 $OWHOME 27, 67 OWSYS 36, 37, 80 OWSYSP 80 OWSYSSID 27, 28, 29, 35, 36, 37 P pd 64, 67 PdEx 64, 67 .plist.tmp 69
Index 109
Landmark
Pointing Dispatcher 64 starting/stopping 64 priority list none 39 processes at OpenWorks startup 66 system checking 5-10 killing 8-9 starting 7 See also OpenWorks system processes and System processes Project Query tool 20-21 projects in ORACLE but not in OpenWorks deleting 41 in Oracle but not in OpenWorks 37 master projects checking with contest2d 52-53 size of, determining 52-53 ps command 64 R rc.ow 67 Remote Services Daemon 28 resource monitor 67 RSvD 28 Runtime Status Box 5
S sdtperfmeter (Solaris resource monitor) 67 seismic display no color maps 59 no data displayed 59 no dual color bars 59 partial data displayed 59 troubleshooting computed contours 60 troubleshooting well display 61 SeisWorks /tmp directory full 68 sys directory full 69 2D master project 52 2DPlus files 43 3DPlus files 44 cannot make a horizon 47 common error messages 103-106 contest2d utility 52 data access problems 43-47 data loading problems 54 displaying horizons in Map View 49 horizon list incorrect or missing 48 horizon problems 47-49 identifying faults in Map View 50 problems correlating faults 49 problems exporting data 51 problems starting 68 problems with faults 49-51 suspect-looking fault contours 51 temporary files that can be deleted 69 Server Manager, using to query the Oracle database 80-81 SQL
110
Index
R2003.12.0.1
Landmark
using to query the Oracle database 29 SQL*Net V2 Listener Process 32 startow command 66 su command 64, 65 swild.ctr 69 symptoms of trouble 4 system files modifications at OpenWorks installation 67 system processes checking 5-9, 64-67 initiated at OpenWorks startup 66 killing a process 8-9 starting/restarting processes 7-8 starting/stopping 64 T tnsnames.ora 83 troubleshooting basic techniques 3-15 checking for running processes 5 data access problems 26-42 data-related problems 25-55 checklist 26-34 disk space 11 first step 4 killing processes 8-9 Runtime Status Box 5 seismic display problems 57-62 starting processes 7-8 symptoms of trouble 4 system problems 63-69
R2003.12.0.1
system processes 5-10 tools used for 17-24 X 68 U UNIX processes, checking 5-12 See also system processes setting file permissions 44-47 upd.prj 69 W wells problems with well display 61 X X system troubleshooting 68 xosview (Linux resource monitor) 67 Z *zycor.log 69
Index
111

Troubleshooting

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting

Uploaded by

Copyright:

Available Formats

OpenWorks Troubleshooting Guide

2004 Landmark Graphics Corporation

Part No. 161622 R2003.12.0.1

OpenWorks Troubleshooting Guide

OpenWorks Troubleshooting Guide

Tools for Troubleshooting