HowTo: Change VMWare Player OracleEL5 Display Resolution

http://www.devside.net/blog/vmware-player-resolution


Here is one useful bit for anyone running, or thinking of running, a local test/development environment under VMWare Player version 2.0 with a guest OS Linux install.

I’ll assume you have installed VMWare Player and a VMWare Appliance similar to CentOS v5. After which, by default, the resolution will be limited to modes “800×600″ and “640×480″.

Here is how you fix that problem…

Step 1: Install X and GNOME, if not already present.
yum groupinstall "X Window System" "GNOME Desktop Environment"
[Note: to install KDE, substitute the "GNOME..." string with "KDE (K Desktop Environment)"]

Step 2: Edit /etc/X11/xorg.conf

You should already have…

Section "Device"
Identifier "Videocard0"
Driver "vmware"
EndSection

Add the following “monitor” section…

Section "Monitor"
Identifier "Monitor0"
HorizSync 1.0 - 10000.0
VertRefresh 1.0 - 10000.0
EndSection

Modify the existing “Screen” section…
Note to replace the following “1600×1200″ string with the highest resolution your monitor can handle.

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1600x1200" "800x600" "640x480"
EndSubSection
EndSection

Step 3: Start X
startx

Test send email from unix server

$echo "test" | sendmail -v nsanguan@gmail.com


$echo "test" | sendmail -v nsanguan@gmail.com
Warning: .cf file is out of date: sendmail AIX5.3/8.13.4 supports version 10, .cf file is version 9
nsanguan@gmail.com... Connecting to gmail-smtp-in.l.google.com. via esmtp...

Oracle JDeveloper 10.1.3.5 Installation

JDeveloper 10.1.3.x Screen display problems

JDeveloper on Windows using a laptop had serious problems with the display when the IDE tried to scroll as it was leaving visible marks. It ended up that the remedy was

1. Open DEV_HOME/jdev/bin/jdev.conf file
2. Search AddVMOption -Dsun.java2d.noddraw=true
3. Enable this line by remove #

Super fast Database Copying/Cloning

Oracle Tips by Burleson Consulting

A database cloning procedure is especially useful for the DBA who wants to give his developers a full-sized TEST and DEV instance by cloning the PROD instance into the development server areas.

This Oracle clone procedure can be use to quickly migrate a system from one UNIX server to another. It clones the Oracle database and this Oracle cloning procedures is often the fastest way to copy a Oracle database.

STEP 1: On the old system, go into SQL*Plus, sign on as SYSDBA and issue: “alter database backup controlfile to trace”. This will put the create database syntax in the trace file directory. The trace keyword tells oracle to generate a script containing a create controlfile command and store it in the trace directory identified in the user_dump_dest parameter of the init.ora file. It will look something like this:

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "OLDLSQ" NORESETLOGS
NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 240
MAXINSTANCES 1
MAXLOGHISTORY 113
LOGFILE
GROUP 1 ('/u03/oradata/oldlsq/log1a.dbf',
'/u03/oradata/olslsq/log1b.dbf') SIZE 30M,
GROUP 2 ('/u04/oradata/oldlsq/log2a.dbf',
'/u04/oradata/oldlsq/log2b.dbf') SIZE 30M
DATAFILE
'/u01/oradata/oldlsq/system01.dbf',
'/u01/oradata/oldlsq/mydatabase.dbf'
;
# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;


STEP 2: Shutdown the old database

STEP 3: Copy all data files into the new directories on the new server. You may change the file names if you want, but you must edit the controlfile to reflect the new data files names on the new server.

rcp /u01/oradata/oldlsq/* newhost:/u01/oradata/newlsq
rcp /u01/oradata/oldlsq/* newhost:/u01/oradata/newlsq
rcp /u03/oradata/oldlsq/* newhost:/u03/oradata/newlsq
rcp /u04/oradata/oldlsq/* newhost:/u04/oradata/newlsq


STEP 4: Copy and Edit the Control file – Using the output syntax from STEP 1, modify the controlfile creation script by changing the following:

Old:

CREATE CONTROLFILE REUSE DATABASE "OLDLSQ" NORESETLOGS

New:

CREATE CONTROLFILE SET DATABASE "NEWLSQ" RESETLOGS

STEP 5: Remove the “recover database” and “alter database open” syntax

# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;


STEP 6: Re-names of the data files names that have changed.

Save as db_create_controlfile.sql.

Old:

DATAFILE
'/u01/oradata/oldlsq/system01.dbf',
'/u01/oradata/oldlsq/mydatabase.dbf'

New:

DATAFILE
'/u01/oradata/newlsq/system01.dbf',
'/u01/oradata/newlsq/mydatabase.dbf'

STEP 7: Create the bdump, udump and cdump directories

cd $DBA/admin
mkdir newlsq
cd newlsq
mkdir bdump
mkdir udump
mkdir cdump
mkdir pfile


STEP 8: Copy-over the old init.ora file

rcp $DBA/admin/olslsq/pfile/*.ora newhost:/u01/oracle/admin/newlsq/pfile

STEP 9: Start the new database

@db_create_controlfile.sql

STEP 10: Place the new database in archivelog mode

Config SVN on Redhat AS4

1. Download SVN

http://www.collab.net/downloads/subversion/redhat.html

CollabNetSubversion-client-1.5.5-1.i386.rpm
CollabNetSubversion-server-1.5.5-1.i386.rpm
CollabNetSubversion-extras-1.5.5-1.i386.rpm

2. Install SVN Client,SVN Server and SVN extras by sequence

$rpm -ivh /home/svn/CollabNetSubversion-client-1.5.5-1.i386.rpm
$rpm -ivh /home/svn/CollabNetSubversion-server-1.5.5-1.i386.rpm
$rpm -ivh /home/svn/CollabNetSubversion-extras-1.5.5-1.i386.rpm

edit .bash_profile
$vi .bash_profile
---------------------------------------------------------------------
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin:/opt/CollabNet_Subversion/bin

export PATH
unset USERNAME
--------------------------------------------------------------------

3. Configuration SVN

$/opt/CollabNet_Subversion/bin/Configure-CollabNet-Subversion

Redhat Command

rpm -Uvh /home/applmgr/connect-proxy-1.93-2.el3.at.i386.rpm

Grant Remote SYSDBA

http://www.orafaq.com/wiki/Oracle_database_Security_FAQ

Managing administrative (privileged) users and password files

An administrative account is a user that is granted SYSOPER or SYSDBA privileges. Oracle DBAs and operators typically use administrative accounts to manage the database and database instance.

SYSDBA and SYSOPER allow access to a database instance even if it is not running. Control of these privileges is managed outside of the database via password files and special operating system groups (dba on Unix/Linux and ORA_DBA on Windows). External password files are created with the orapwd utility.

Connecting as an administrative user:

If an administrative users belongs to the "dba" group on Unix, or the "ORA_DBA" (ORA_sid_DBA) group on Windows, he/she can connect like this:

connect / as sysdba

No password is required. This is equivalent to the desupported "connect internal" method.

A password is required for "non-secure" administrative access. These passwords are stored in password files. Remote connections via Net8 are classified as non-secure. Look at this example:

connect sys/password as sysdba

Password files:

The Oracle Password File ($ORACLE_HOME/dbs/orapw or orapwSID) stores passwords for users with administrative privileges. One needs to create a password files before remote administrators (like OEM) will be allowed to connect.

Follow this procedure to create a new password file:

• Log in as the Oracle software owner
• Run command: orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=mypasswd
• Shutdown the database (SQLPLUS> SHUTDOWN IMMEDIATE)
• Edit the INIT.ORA file and ensure REMOTE_LOGIN_PASSWORDFILE=exclusive is set.
• Startup the database (SQLPLUS> STARTUP)[/list]

NOTE: The orapwd utility presents a security risk in that it receives a password from the command line. This password is visible in the process table of many systems. Administrators needs to be aware of this!

Adding users to Password File:

One can select from the SYS.V_$PWFILE_USERS view to see which users are listed in the password file. New users can be added to the password file by granting them SYSDBA or SYSOPER privileges, or by using the orapwd utility.

GRANT SYSDBA TO scott;