What to Do If the Root Password Is Lost in sun solaris operating system?

1) Insert the Solaris Operating System CD-ROM into the CD-ROM drive.

2) Once the CD-ROM is in the drive, perform a stop-a command. This brings the system down to the ok prompt.

3) From the ok prompt, perform a single-user boot from the Solaris 2.x installation CD-ROM.

ok  boot cdrom -s

4) At the "#" prompt, try to determine which disk is the system's boot disk (containing the root file system).

There are several Sun architectures and various configurations of the systems when it comes to a boot disk. As a general rule, most boot disks are attached to controller 0 (c0). Usually, their SCSI target is either 3 (t3) or 0 (t0). However, because Sun machines are very flexible, the boot disk could be at a different location.

NOTE: If your boot disk is MIRRORED using Solaris Disksuite[TM] or Solaris[TM] Volume Manager software, "Solaris[TM] Volume Manager software and Solstice DiskSuite[TM] software: Mounting metadevices" This article explains how to mount a metadevice without breaking the integrity of the mirrored data.

5) At the "#" prompt, enter the following:

# eeprom boot-device

The output might appear to be simple, such as "disk" or "disk1," or as a pathname "/iommu/sbus/espdma@4,8400000/...../sd@3,0:a". Make note of the boot-device. If the boot-device is a pathname, it is beyond the scope of this Technical Instruction to provide the location of the customized boot disk. However, for most configurations, you can find the location easily.

6) The "Format" command shows you all available disks:

# format

    Searching for disks...done

    AVAILABLE DISK SELECTIONS:

           0. c0t0d0 

             /pci@1f,0/pci@1,1/ide@3/dad@0,0

    Specify disk (enter its number):

7) Press d to exit format.

Now, you will have an idea what disks are on the system. If the boot-device is "disk" and the format shows "c0t0d0" (or on some systems "c0t3d0"), then that is a boot device. If the boot-device shows "disk1" and the format shows "c0t1d0," then that is the boot device. If format shows multiple disks, then based on what the "eeprom boot-device" command shows, the boot disk would be:

boot-device        format

disk               c0t0d0 or c0t3d0 (machine dependent)

disk1              c0t1d0

disk2              c0t2d0

disk3              c0t3d0 or c0t0d0 (machine dependent)

and so on ....

8) Because the system was not brought down gracefully (no root password, means having to use the Stop-a keystroke to "crash" the system), you should run "fsck" to clean the root partition (slice). Fsck also confirms that you selected the proper slice:

   # fsck /dev/rdsk/cXtYd0s0

where the X and Y are determined by the previous procedure . It is also possible to have a root partition that is not on slice 0 (s0), but, again, that is not a standard configuration. The output of "fsck" will look like this:

** /dev/rdsk/c0t0d0s0

** last mounted on /

** Phase 1 .....

.....

The second line "** Last mounted on /" confirms that this is the correct root fs partition.

9) Answer "y" to any questions fsck asks. There shouldn't be too many items needing repair. If there are numerous items needing repair, then there could be a corrupted root fs.

10) After fsck is finished, you can mount the root partition:

# mount /dev/dsk/cXtYd0s0 /a

Again, X and Y are same as for the fsck command.

Example:

# mount /dev/dsk/c0t0d0s0 /a

11) From the root prompt, enter the following command:

# TERM=sun; export TERM

12) Edit the /etc/shadow file:

# vi /a/etc/shadow

The first line of the file is almost always the one you want to modify. The first line looks like this:

root:c3.yAVmYodWsc:6445::::::

13) Delete every character between the first and second colons in the first line.

When you finish the process, the first line should look like this:

root::6445::::::

14) After you delete the characters in the first line, enter the following (in the command mode) to perform a write force quit to exit the document and save the changes:

:wq!

15) Unmount the file system, as follows:

# cd /
# umount /a

16) Reboot the system:

# reboot

The preceding command shuts down the system and brings it back up in multi-user mode.

17) At the login window, log in as root. You should get in automatically.

18) Change the root password immediately.

ORA-845: MEMORY_TARGET not supported on this system on linux in oracle 11g or ORA-04031

This is for initialization parameter MEMORY_TARGET or MEMORY_MAX_TARGET value.

This value cannot be greater than the shared memory filesystem (/dev/shm) on you linux system. Or This error may also occur if /dev/shm is not properly mounted. Make sure in your df -k output filesystem shmfs is mounted

To know the shared memory filesystem issue following command.

# df –k /dev/shm

To resolve the current error, increase the /dev/shm file size.

For example:

# mount -t tmpfs shmfs -o size=60g /dev/shm

To make this change permanant, add an line in /etc/fstab like following:

shmfs /dev/shm tmpfs size=60g 0

In sun solaris operating system check the value of “shmsys:shminfo_shmmax” in following location.

/etc/project and /etc/system

ORA-00604: error occurred at recursive SQL level 1 ORA-01422: exact fetch returns more than requested number of rows

its for dual table (more then one row)

Even Oracle 10gR1 and above always makes sure that DUAL returns one and only one row even if it contains more than one row.

still you can get below error for more rows in dual table.

 SQL> drop table drop_test ; 
drop table drop_test 
* 
ERROR at line 1: 
ORA-00604: error occurred at recursive SQL level 1 
ORA-01422: exact fetch returns more than requested number of rows 

(note:- don't play with dual table in production database ever)

examples ;-

 SQL*Plus: Release 10.2.0.1.0 - Production on Sun Nov 20 10:19:55 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn sys@orcl105 as sysdba
Enter password:
Connected.
SQL>
SQL>
SQL> select sysdate from dual ;
SYSDATE
---------
20-NOV-11
SQL>
SQL> select * from dual ;
D
-
X
SQL>
SQL>
SQL>
SQL> insert into dual values ('H') ;
1 row created.
SQL> commit ;
Commit complete.
SQL>
SQL> create table dual_two_row as select * from dual ;
Table created.
SQL>
SQL>
SQL> select * from dual_two_row ;
D
-
X
H
SQL> select * from dual ;
D
-
X
SQL>
SQL>
SQL> create table drop_test (id number) ;
Table created.
SQL>
SQL> insert into drop_test values(5);
1 row created.
SQL> commit ;
Commit complete.
SQL>
SQL> drop table drop_test ;
drop table drop_test
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01422: exact fetch returns more than requested number of rows
SQL>
SQL>
SQL> select * from dual ;
D
-
X
SQL> drop table dual_two_row ;
drop table dual_two_row
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01422: exact fetch returns more than requested number of rows
SQL> select * from dual ;
D
-
X
SQL> create table dual_new as select * from dual ;
Table created.
SQL>
SQL> select * from dual_new ;
D
-
X
H
SQL> delete from dual where dummy='H' ;
1 row deleted.
SQL> commit ;
Commit complete.
SQL>
SQL> drop table dual_two_row ;
Table dropped.
SQL>
SQL> drop table drop_test ;
Table dropped.
SQL>
SQL> drop table dual_new ;
Table dropped.
SQL>
SQL>
SQL> select * from dual ;
D
-
X
SQL>
SQL>
SQL>
SQL> select * from v$version ;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE  10.2.0.4.0   Production
TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL>
SQL>

see more about dual table ...

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1562813956388

http://awads.net/wp/2005/11/08/insert-into-dual/

http://sriramoracle.wordpress.com/2011/05/04/all-about-special-dual/

ORA-00257: archiver error. Connect internal only,until freed.

*Cause: The archiver process received an error while trying to archive
a redo log. If the problem is not resolved soon, the database
will stop executing transactions. The most likely cause of this
message is the destination device is out of space to store the
redo log file.

*Action: Check archiver trace file for a detailed description
of the problem. Also verify that the
device specified in the initialization parameter
ARCHIVE_LOG_DEST is set up properly for archiving.


Explanation:-

The archiver process received an error while trying to archive a log.
The database will stop executing transactions.
The cause of this error is the archive destination device is out of space.
This will stop the system from working allowing only internal to connect.



solution:-

1)

Sql> conn / as sysdba

sql> archive log list;

---see the Archive Destination and
---increase the size of that location

suppose if archive destination is USE_DB_RECOVERY_FILE_DEST

then increase the size with following command.

SQL> alter system set db_recovery_file_dest_size=3G ;


2) backup your database and archive logs to somewhere else then delete archive log file via Rman

RMAN> connect target sys/sys@orcl as sysdba

RMAN> delete archivelog all ;


3) also you can configure

set the following parameters so that when the dest1 is full, archiving is automatically performed to the alternate dest2 :

log_archive_dest_1='LOCATION=use_db_recovery_file_dest NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_2'
log_archive_dest_2='LOCATION=/other_dest_for_archiving'
log_archive_dest_state_1='enable'
log_archive_dest_state_2='alternate'
db_recovery_file_dest='/u01/app/oracle/product/10.1.0/db_1/flash_recovery_area'
db_recovery_file_dest_size=2G

ORA-32004:obsolete and/or deprecated parameter(s) specified

Clue:= when you trying to startup your database you face this error

this means you set up a obsolete and/or deprecated parameter in database parameter file.

for this this error is showing .

so now you should check parameter file which is using when database is starting up.

and remove the obsolete and/or deprecated parameter then startup the database.

Now question is:- how can you find out of this obsolete and/or deprecated parameter?

Answer are :-

1)Look at the alert log of the associated instance (at the time that an instance startup is initiated)

it show the parameter with this "obsolete and/or deprecated" message.

like below

Deprecated system parameters with specified values:

(your Deprecated parameters)

End of deprecated system parameter listing

2) or if database is accessable then query this view V$OBSOLETE_PARAMETER

3) or read the document of the current database version and identified from the list of deprecated parameters