Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

PB Starting UP Database

Posted on 2004-09-19
14
Medium Priority
?
1,489 Views
Last Modified: 2008-01-09
Hello,

I delete an old Oracle Database installation folder three.
When I tried to startup my new database, I got an:

ORA-07446: sndfy: bad value '/u01/app/oracle/admin/oraclelx/udump'
                   for parameter user_dump_dest

1) How can I resolve this issue ?

PT
0
Comment
Question by:ptreves
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 5
14 Comments
 
LVL 7

Expert Comment

by:BobMc
ID: 12097349
The directory specified for udump does not exist.
in your init.ora file (probably '/u01/app/oracle/admin/<SID>/pfile/init<SID>.ora'), find the entry for user_dump_dest, and set it to a valid directory, then try to start your db again
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097424
Or just to create a new directory by that name:

$ mkdir -p /u01/app/oracle/admin/oraclelx/udump
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097428
then you should be able to start up the database.
0
Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

 

Author Comment

by:ptreves
ID: 12097626
I checked and don't have any init<SID>.ora file anymore

My directory three ends at :

/u01/app/oracle_linux/admin

Nothing underneeth

1) What should I do now ?
2) Can I copy an  Oracle 8i init.ora file to my linux Oracle 9i database ?

PT
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097645
ok, you don' t need to.

Here is what you are gonna do....

go ahead to create the new directory like I said above:
$ mkdir -p /u01/app/oracle/admin/oraclelx/udump


then startup database as normal:

$sqlplus /nolog
SQL>connect / as sysdba
SQL>shutdown immediate; --make sure the database is completely down.


then issue startup , see what happens..


SQL>startup

0
 

Author Comment

by:ptreves
ID: 12097660
Hello,

Ok, I created the directory mentionned.
I try to shutdown the database to restartit and I get the following error:

ORA-24324: Service handle not initialised
ORA-24323: value not allowed
ORA-01090: shutdown in progress connection is not allowed

1) What should I do now ?

PT
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097700
then you can force the Oracle database down in either of two ways:

but I will recommend you only one way because it's just darn simple.

REBOOT the machine.

when the machine comes back up,

try my above commands...
0
 

Author Comment

by:ptreves
ID: 12097737
Hello,

Ok, I rebooted the server.
I did:

sqlplus /nolog
connect system/manager as sysdba
startup

and I got:

ORA-00449: background process 'CKPT' unexpectedly terminated with error 7446
ORA-07446: sdnfy: bad value for parameter

1) What now ?

PT
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097749
Ok, then, can you post the init<SID>.ora file --This <SID> will be your database name.

this file is located in $ORACLE_HOME/dbs folder...
0
 

Author Comment

by:ptreves
ID: 12097799
Hello,

I have 3 *.ora files in that folder.
One spfileORCLNX.ora, one init.ora and one initdw.ora.
My SID is ORCLLNX.ora:

Here is the initdw.ora file:
=====
#***********************************************************************
# Example INIT.ORA file for data-warehousing applications
#***********************************************************************
# This file is provided by Oracle Corporation to help you customize
# your RDBMS installation for your data warehousing or
# business intelligence application. The primary purpose of this file
# is to provide a starting point for parameter settings in a
# data-warehouse. This file is designed for release 9.0.
#
# All of the parameters in this file and discussed in more detail
# in the documentation. This file should be used for guidance
# on the setting of parameters, not as a reference for parameters.
#
# 'Data warehousing' is an expansive term. In general, this parameter
# file assumes that a data warehouse is characterized by:
#   - end-users execute only queries (rather than updates)
#   - end-user queries often examine large amounts of data
#   - data-loading and updating is managed in separate operations;
#      often, data-modifications occur during batch operations although
#      some data warehouses receive new data throughout the day
#
# Some parameter settings are generic to any data-warehouse application.
# Other parameters depend upon the size of the data warehouse; different
# settings are provided for these parameters, for the following categories
# of data warehouses:
#      Category      Size of raw data      CPUs      Memory
#      DEMO          <1GB                  1         128MB
#      SMALL         <100GB                4         ~1GB
#      MEDIUM        100-500GB             4-12      4-10GB
#      LARGE         >500GB                12-16+    >10GB
# 'Raw data' refers to the size of the actual data, and does not
# include index space or temp space.
#
# The uncommented parameters in this init.ora file are configured for
# a 'demo' system. These parameters are suitable for using the 'Sales
# History' Schema (a sample data warehouse schema, which is included
# on the Oracle9i CD), which is used throughout Oracle's documentation
# and training related to data warehousing. Most customers will be
# able to install and run this schema on a single-CPU workstation.
#
# More detailed information on all parameters can be found in the
# in the documentation.
#
# This parameter file provide initial guidelines for the configuration
# parameters of a data warehouse. Using these guidelines, you should
# be able to achieve good performance for a wide variety of data
# warehouse applications. However, further tuning of these parameters
# for a specific application may yield improved performance.
#
# INSTRUCTIONS: Edit this file and the other INIT files at your site,
# either by using the values provided here or by providing your own.
# If you are using Oracle Real Application Clusters, place an IFILE=
# line into each instance-specific INIT file that points at this file.


#***********************************************************************
# Database parameters
#***********************************************************************


# Database blocks should be large in data warehouses. This improves
# performance for operations involving large amounts of data.
db_block_size = 8192

# For a large data warehouse, db_files should be set to a large value.
#db_files = 1000

#***********************************************************************
# Memory parameters
#***********************************************************************

# In a data warehouse, the majority of physical memory will be
# allocated for the one of the following two purposes:
#    Runtime memory: used for sorting and hashing data during query processing
#       (governed by the parameter pga_aggregate_size)
#    Data caching: used to accelerate performance by avoid disk accesses
#       (governed by the parameter db_cache_size)
# Additionally, a significant amount of memory may need to be allocated for:
#    Shared pool: used for storing shared memory constructs
#       (governed by the parameter shared_pool_size)
#    Large pool: used during parallel-execution processing
#       (governed by the parameter large_pool_size)
#
# Memory is managed globally. The DBA should first determine how much
# memory is available for Oracle to use. Then, the DBA should choose
# memory parameters so that pga_aggregate_size + db_cache_size +
# shared_pool_size + large_pool_size is roughly equal to the amount
# of memory available for the Oracle database.
#
# For example, suppose that a DBA is managing a small data mart. The
# data mart server has 1GB of physical memory. The DBA has determined
# that 500M of memory will be used by the operating system and other
# applications, so that 500M is available for Oracle.
#
# The DBA may choose the following settings:
#   shared_pool_size = 50M
#   pga_aggregate_size = 200M
#   db_cache_size = 200M
#   large_pool_size = <default>
#
# The total memory utilization is 450M plus a system-determined value
# for the large pool.
#
# The following sections discuss each of these memory-related
# parameters in more detail. These examples assume that the data
# warehouse server has 1GB, 8GB, and 16GB respectively for small,
# medium, and large configurations.


# Runtime memory (the memory used for sorting and hashing during query
# execution) is automatically and globally managed when the
# pga_aggregate_target parameter is set. For data warehouse workloads
# which involve sorts and joins of large volumes of data, the
# pga_aggregate_target should be set to a large value.
#
# pga_aggregate_target should, in general, be equal to 20-80% of the
# available memory, depending on the workload. The values below assume
# a mixed data-warehouse workload.
#
# This parameters (introduced in Oracle9i) replaces all of the
# following parameters: hash_area_size, sort_area_size,
# create_bitmap_area_size, and bitmap_merge_area_size


pga_aggregate_target = 30M                                #DEMO
#pga_aggregate_target = 200M                              #SMALL
#pga_aggregate_target = 3000M                             #MEDIUM
#pga_aggregate_target = 6000M                             #LARGE


# The database cache is also a globally-managed portion of memory. The
# database cache should be set to a large value for data warehouse
# workloads which involves short-running queries and/or the access of
# small tables and indexes.
#
# db_cache_size should, in general, be equal to 20-80% of the
# available memory, depending on the workload. The values below assume
# a mixed data-warehouse workload.
#

db_cache_size = 30M                                #DEMO
#db_cache_size = 200M                              #SMALL
#db_cache_size = 3000M                             #MEDIUM
#db_cache_size = 6000M                             #LARGE


# Shared pool size should be, in general, equal to 5-10% of the
# available memory. Data warehouses typically do not require as much
# memory for shared pool as OLTP systems.

shared_pool_size = 20M                                   #DEMO
#shared_pool_size = 50M                                  #SMALL
#shared_pool_size = 400M                                 #MEDIUM
#shared_pool_size = 800M                                 #LARGE


# The default for large_pool_size should appropriate for most
# environments.
#
# The Large Pool is used for several purposes. In a data warehouse the
# majority of the space in the Large Pool will be used for
# parallel-execution internal message buffers. The amount of memory
# required by parallel-execution is proportional to the product of the
# number of concurrent parallel-execution users and the square of the
# number of CPU's.
#
# The documentation describes in detail how to estimate the default size
# of the Large Pool, and the conditions under which this parameter
# should be set explicitly.
#
# Here are some very general estimates on the amount of memory required
# for the Large Pool based on the number of CPU's:
#    4 cpus:  5M  (with parallel_threads_per_cpu = 4)
#    8 cpus:  5M  (with parallel_threads_per_cpu = 2)
#    8 cpus: 20M  (with parallel_threads_per_cpu = 4)
#   16 cpus: 20M  (with parallel_threads_per_cpu = 2)
#   32 cpus: 80M  (with parallel_threads_per_cpu = 2)
#
# The Large Pool is only used for parallel-execution message buffers
# when parallel_automatic_tuning is enabled. If
# parallel_automatic_tuning is not utilitized, then parallel-execution
# message buffers are stored in the shared pool, and the
# shared_pool_size parameter should be adjusted appropriately.


#***********************************************************************
# Parallel Execution parameters
#***********************************************************************


# Parallel execution parameters were greatly simplified in Oracle8i.
# Data warehouses developed on older releases of Oracle may use
# different init.ora parameters. While these older parameters continue
# to be supported, these parameters below are recommended for all new
# data warehouses, and should be considered when upgrading data
# warehouses from previous releases.

# Setting parallel_automatic_tuning will result in the database
# configuring itself to support parallel execution.
parallel_automatic_tuning = true

# This parameter determines the default number of parallel execution
# processes. Typically, 2 parallel processes per CPU provides good
# performance. However, for systems with a smaller number of CPUs or
# for systems in which the IO subsystem is slow relative to the the
# CPU's, more parallel processes may be desired and the value of this
# parameter may be increased.
parallel_threads_per_cpu = 4                                 #SMALL
#parallel_threads_per_cpu = 2 or 4                           #MEDIUM
#parallel_threads_per_cpu = 2                                #LARGE


#***********************************************************************
# Optimizer and query parameters
#***********************************************************************

# All data warehouses should use the cost-based optimizer. All basic
# data warehouse performance features, such as star-query support,
# hash joins, parallel execution, and bitmap indexes are only
# accessible via the cost-based optimizer.
optimizer_mode = choose

# When using a star schema, set this parameter to true.
star_transformation_enabled = true


#***********************************************************************
# IO parameters
#***********************************************************************

# Multiblock reads allow for the database to retrieve multiple
# database blocks in a single IO. In general, a high multiblock read
# count provides better performance, particularly for operations on
# large volumes of data. Oracle supports IO's up to 1MB on many
# platforms. Disk striping will also affect the value for multiblock
# read count, since the stripe size should ideally be a multiple of
# the IO size.

# If you are gathering optimizer system statistics (see DBMSSTAT.SQL
# for more information), then you should set this parameter to a high
# value.
#db_file_multiblock_read_count = 64

# If you are not gathering optimizer system statistics, then you
# should set this parameter to a lower value.
db_file_multiblock_read_count = 16



#***********************************************************************
# Materialized view parameters
#***********************************************************************

# This parameter enables the use of materialized views for improved
# query performance.
query_rewrite_enabled = true

# This parameter determines the degree to which Oralce enforces
# integrity rules during query rewrite. In most data-warehouse
# environment, 'trusted' is the appropriate setting.
query_rewrite_integrity = trusted



#***********************************************************************
# Compatibility
#***********************************************************************

# When building a new application, both compatibility and
# optimizer_features_enabled should be set to the current release to
# take advantage of all new features. If you are upgrading an existing
# application to Oracle9i, then you may want to consider setting one
# or both of these parameters to an earlier release.
#compatible = 9.0
#optimizer_features_enabled = 9.0


#***********************************************************************
# Other Parameters
#***********************************************************************


# This section lists other parameters that, although not specific
# to data warehousing, are required for any Oracle database. By
# uncommenting these parameters, this parameter file can be used
# as a complete stand-alone init.ora file.

====
I will post the other files,.

PT

0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097833
Ok, before you post those up, you can try this too...


I think This will fix your problem altogether.

You should create these directory along:

$ mkdir -p /u01/app/oracle/admin/oraclelx/udump
$ mkdir -p /u01/app/oracle/admin/oraclelx/bdump
$ mkdir -p /u01/app/oracle/admin/oraclelx/cdump
$ mkdir -p /u01/app/oracle/admin/oraclelx/pfile



after that, I am afraid that you have to reboot the machine again.

after the machine is up:

$sqlplus /nolog
SQL>connect system/manager as sysdba
SQL>startup
0
 
LVL 23

Expert Comment

by:seazodiac
ID: 12097835
oh, another piece of advice, Don't EVEN try to tamper with SPFILE<SID>.ora file.
0
 

Author Comment

by:ptreves
ID: 12097933
Hello,

Ok. BINGO !!!!!!!!!
I started my DB with success.

Thanks alot.

I still have a number of other issues with the Web Deployment of my WebForms application:

1) FRM-40039: Cannot attach library HINT while opening form Tbprjnew.

How can I resolve this problem ?

PT

PS: BOth my tbprjnew.fmx and HINT.pll are in the forms90 subfolder ...

0
 
LVL 23

Accepted Solution

by:
seazodiac earned 2000 total points
ID: 12097943
Not a problem, it's becoming my hobby to hang out here.....

I cannot help with your other problem (FRM-40039)  though....
0

Featured Post

Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Truncate is a DDL Command where as Delete is a DML Command. Both will delete data from table, but what is the difference between these below statements truncate table <table_name> ?? delete from <table_name> ?? The first command cannot be …
When it comes to protecting Oracle Database servers and systems, there are a ton of myths out there. Here are the most common.
This video shows setup options and the basic steps and syntax for duplicating (cloning) a database from one instance to another. Examples are given for duplicating to the same machine and to different machines
This videos aims to give the viewer a basic demonstration of how a user can query current session information by using the SYS_CONTEXT function

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question