MariaDB and MySQL performance boost using noatime. Take a peek at your filesystem mount file on your Linux Box /etc/fstab
/dev/VolGroup01/LogVol01 /data ext3 defaults 0 0
In many cases just like the above you'll see that MySQL data location is mounted with "defaults" options - in our case MySQL data files are located in /data partition.
What does it mean? It means that you are taking a performance hit every time the file is accessed (read or write) on your file system. There is a record created i.e. physically written to the file system, that is besides MySQL access.
The issue is that if you do not explicitly specify "noatime" mount option for your ext3 file system the default "atime" will be used. This option is constantly writing to the disk bogging down your io performance. Unless you have a specific need for "atime" you are wasting io resources especially if you are using database system.
Now to the "noatime", "noatime" writes to the disk every time a particular file was modified, i.e. unlike "atime" the file must be physically modifies in order for "noatime" to generate a physical white to the disk, thus dramatically reducing your io and boosting performance.
So how do you take advantage of this performance boosting option - very simple. Dismount your filesystem using umount - umount /data, modify the mounting option by adding noatime and mount the filesystem back. By far the easiest performance gain in one line modification. Of course be sure to shut down your MariaDB prior to the unmout/mount. Once completed your /etc/fstab will look like this:
LVM - or simply Logical Volume Manager, Linux LVM is the implementation of Logical Volume Manager for the Linix kernel. Most of the Linux distributions include LVM. Besides obvious benefits of using Logical Volume Manager there is also a great feature - LVM snapshot capability that is included in Linux LVM
LVM snapshot is an awesome tool that is included with your Linux distribution at no charge to you! LVM snapshot allows you to create a new block device that is the exact copy of the logical volume frozen in time.
Why this is such a great capability? Say you have a 500GB database and need to create a replicated slave or take a database backup. In order to do that you have to resort to one of the following:
1. Stop the database (or flush tables with read lock) and copy the files - that could take several hours.
2. Use INNODB backup tools - still will take quite some time and that does not copy your MYISAM tables
3. Use MySQL dump - not even practical for 500 GB database could take days!
Enter the LVM snapshot greatness - very simple, fast and least downtime way to create your MySQL backup and recovery strategy. Most importantly unlike dedicated storage engine backup solutions (IBBACKUP etc...) LVM snapshot will work with your MYISAM tables also.
Here's how to implement it:
First and foremost you must have LVM enabled, assuming that you have you can use LVM commands to explore your logical volumes. LVM commands are located in /sbin/ directory.
Start using LVM
[root@db22 /]# ./sbin/lvm
lvm>
View your logical volumes:
[root@db22 /]# ./sbin/lvm
lvm> lvdisplay
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID u8PhLr-6dfg-WcmL-qzCr-4E6a-2wYB-IlNsrh
LV Write Access read/write
LV Status available
# open 1
LV Size 31.66 GB
Current LE 1013
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID gA8rvW-QwxV-GbLB-KADy-Ank9-9vJx-D3VKz0
LV Write Access read/write
LV Status available
# open 1
LV Size 1.94 GB
Current LE 62
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:1
--- Logical volume ---
LV Name /dev/VolGroup01/LogVol01
VG Name VolGroup01
LV UUID KLND46-bfYW-MpaZ-hr2y-6nF4-L1yo-zeT4Zr
LV Write Access read/write
LV Status available
# open 1
LV Size 772.91 GB
Current LE 197866
Segments 2
Allocation inherit
Read ahead sectors 0
Block device 253:2
lvm>
Now you can figure out which logical volume is hosting your database data by viewing /etc/fstab file - your Linux partition mount file:
Based on the output of /etc/fstab we can determine that our MySQL data is located in /data mount point that in turn is on /dev/VolGroup01/LogVol01 logical volume. Very easy.
Now to the creating the actual snapshot of the logical volume
/dev/VolGroup01/LogVol01:
Since the data we are taking snapshot of is dynamic (that is true of all database systems), we need to place MySQL in read-only mode for the duration of time it take to create a snapshot in many cases less then a minute:
mysql> flush tables with read lock;
You must maintain the lock while the LVM snapshot is being taken. If you exit your mysql session the tables will be unlocked. There several ways to assure that the tables remain locked:
Stay in your mysql session open another terminal and run snapshot
Place mysql> session in the backround using "CTRL+z" (to get back to it use "fg" command"
Run mysql> session in screen
That will stop the updates to the MySQL tables so we can generate a "consistent" view of the data using LVM snapshot.
Since we know the name of the volume we are planning to use /dev/VolGroup01/LogVol01 we will use the LVM and create a snapshot as follows:
Once snapshot is created be sure to unlock MySQL tables:
mysql> unlock tables;
Where is "snap" the name of our snapshot volume and "/dev/VolGroup01/LogVol01" is the name of the volume where MySQL data is located, "L2000M" is the size of the snapshot in megabytes.
Once the snapshot is create we can view it using lvm tool "lvdisplay":
--- Logical volume ---
LV Name /dev/VolGroup01/snap
VG Name VolGroup01
LV UUID ze9d5L-LQWa-bsxY-ubI2-eyYy-t3Uw-v5EbXI
LV Write Access read/write
LV snapshot status active destination for /dev/VolGroup01/LogVol01
LV Status available
# open 0
LV Size 772.91 GB
Current LE 197866
Once the snapshot volume is created it must be mounted to copy the data from it, in order to do that new snapshot volume must be mounted:
Oracle Releases "MySQL: A guide to High Availability Solutions". There are several commonly accepted requirements in order to be called a "Guide" such as be informative and attempt to include all of the solutions available.
Oracle's so-called Guide missed all of the above it failed to include:
1. Continuent Tungsten HA 2. Schooner Replication 3. Red Hat Cluster 4. VCS 5. Percona MMM 6. DRBD
But the so-called Guide did not stop there, "The Guide" also miserably fails to even attempt to be informative. It briefly describes solutions already widely known such as replications and MySQL Cluster - Wooo Hoo we have known about those some some time now ...ahhh nearly a decade.
Instead the guide goes into page filling "blah...blah" about causes of failures and meaningless charts. No mention about the best practices or even practical approach to HA.
In conclusion "The Guide" is not a Guide at all but rather a weak sales brochure.
So Microsoft goes out and buys Skype - probably not a very wise move for the company that currently focused primarily on suing various companies over "patent infringements". Ok all the patents lawsuits aside they have themselves Skype that in turn runs on PostgreSQL and consequently on some flavor of Linux.
Hmmm a tough one - "To migrate or Not To Migrate?!" - that is the question...
By "migrate" I mean from trusted and proved Linux/Postgres combination to Windows (that btw can barely run my laptop and that is after twenty years into the development!) and SQLServer.
The answer if you have any common sense is a very simple and short - NO. But when last time have you seen any common sense come out of Redmond? This is the same company that requires users to push a "Start" button in order to shutdown the operating system.
RMAN can be used either with or without a recovery catalog. A recovery catalog is a schema stored in a database that tracks backups and stores scripts for use in RMAN backup and recovery situations. Generally, an experienced DBA would suggest that the Enterprise Manager instance schema and RMAN catalog schema be placed in the same utility database on a server separate from the main servers. The RMAN schema generally only requires 15 megabyte per year per database backed up.
The RMAN schema owner is created in the RMAN database using the following steps:
1. Start SQL*Plus and connect as a user with administrator privileges to the database containing the recovery catalog. For example, enter:
CONNECT SYS/oracle@catdb AS SYSDBA
2. Create a user and schema for the recovery catalog. For example, enter:
CREATE USER rman IDENTIFIED BY cat TEMPORARY TABLESPACE temp DEFAULT TABLESPACE tools QUOTA UNLIMITED ON tools;
3. Grant the recovery_catalog_owner role to the user. This role provides all of the privileges required to maintain and query the recovery catalog:
SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
Once the owner user is created, the RMAN recovery catalog schema can be added:
1. Connect to the database that contains the catalog owner. For example, using the RMAN user from the above example, enter the following from the operating system command line. The use of the CATALOG keyword tells Oracle this database contains the repository:
% rman CATALOG rman/cat@catdb
2. It is also possible to connect from the RMAN utility prompt:
% rman
RMAN> CONNECT CATALOG rman/cat@catdb
3. Now, the CREATE CATALOG command can be run to create the catalog. The creation of the catalog may take several minutes. If the catalog tablespace is this user's default tablespace, the command would look like the following:
CREATE CATALOG;
While the RMAN catalog can be created and used from either a 9i or 10g database, the Enterprise Manager Grid Control database must be a 9i database. This is true at least for release 1, although this may change with future releases.
Each database that the catalog will track must be registered.
Registering a Database with RMAN
The following process can be used to register a database with RMAN:
1. Make sure the recovery catalog database is open.
2. Connect RMAN to both the target database and recovery catalog database. For example, with a catalog database of RMANDB and user RMAN, owner of the catalog schema, and the target database, AULT1, which is the database to be backed up, database user SYS would issue:
If the instances use archive logs, RAC requires that a channel connection be specified for each instance that will resolve to only one instance. For example, using the AULT1 and AULT2 instances from the previous example:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE DEVICE TYPE TO sbt PARALLELISM 2; CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT = 'SYS/kr87m@ault1'; CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT = 'SYS/kr87m@ault2';
This configuration only has to be specified once for a RAC environment. It should be changed only if nodes are added or removed from the RAC configuration. For this reason, it is known as a persistent configuration, and it need never be changed for the life of the RAC system. This configuration requires that each of the specified nodes be open, the database is operational, or closed, the database shutdown. If one specified instance is not in the same state as the others, the backup will fail.
RMAN is also aware of the node affinity of the various database files. The node with the greatest access will be used to backup those datafiles that the instance has greatest affinity for. Node affinity can, however, be overridden with manual commands, as follows:
The nodes chosen to backup an Oracle RAC cluster must have the ability to see all of the files that require backup. For example:
BACKUP DATABASE PLUS ARCHIVELOG;
The specified nodes must have access to all archive logs generated by all instances. This could entail some special considerations when configuring the Oracle RAC environment.
The essential steps for using RMAN in Oracle RAC are:
* Configure the snapshot control file location.
* Configure the control file autobackup feature.
* Configure the archiving scheme.
* Change the archivemode of the database, although this is optional.
* Monitor the archiver process.
The following section will show how the snapshot control file location is configured.
Clone an Oracle database using RMAN duplicate (same server) tnsManager - Distribute tnsnames the easy way and for free!
This procedure will clone a database onto the same server using RMAN duplicate.
* 1. Backup the source database. To use RMAN duplicate an RMAN backup of the source database is required. If there is already one available, skip to step 2. If not, here is a quick example of how to produce an RMAN backup. This example assumes that there is no recovery catalog available:
rman target sys@ nocatalog
backup database plus archivelog format '/u01/ora_backup/rman/%d_%u_%s';
This will backup the database and archive logs. The format string defines the location of the backup files. Alter it to a suitable location.
* 2. Produce a pfile for the new database This step assumes that the source database is using a spfile. If that is not the case, simply make a copy the existing pfile.
Connect to the source database as sysdba and run the following:
create pfile='init.ora' from spfile;
This will create a new pfile in the $ORACLE_HOME/dbs directory.
The new pfile will need to be edited immediately. If the cloned database is to have a different name to the source, this will need to be changed, as will any paths. Review the contents of the file and make alterations as necessary.
Because in this example the cloned database will reside on the same machine as the source, Oracle must be told how convert the filenames during the RMAN duplicate operation. This is achieved by adding the following lines to the newly created pfile:
* 6. Duplicate the database From sqlplus, start the instance up in nomount mode:
startup nomount
Exit sqlplus, start RMAN and duplicate the database. As in step 1, it is assumed that no recovery catalog is available. If one is available, simply amend the RMAN command to include it.
rman target sys@ nocatalog auxiliary /
duplicate target database to ;
This will restore the database and apply some archive logs. It can appear to hang at the end sometimes. Just give it time - I think it is because RMAN does a 'shutdown normal'.
If you see the following error, it is probably due to the file_name_convert settings being wrong. Return to step 2 and double check the settings.
RMAN-05001: auxiliary filename '%s' conflicts with a file used by the target database
Once the duplicate has finished RMAN will display a message similar to this:
database opened Finished Duplicate Db at 26-FEB-05
RMAN>
Exit RMAN.
* 7. Create an spfile From sqlplus:
create spfile from pfile;
shutdown immediate startup
Now that the clone is built, we no longer need the file_name_convert settings:
alter system reset db_file_name_convert scope=spfile sid='*' /
alter system reset log_file_name_convert scope=spfile sid='*' /
* 8. Optionally take the clone database out of archive log mode RMAN will leave the cloned database in archive log mode. If archive log mode isn't required, run the following commands from sqlplus:
shutdown immediate startup mount alter database noarchivelog; alter database open;
* 9. Configure TNS Add entries for new database in the listener.ora and tnsnames.ora as necessary.
How to bring Oracle Database Back from the Dead or how to open an Oracle database with missing (or deleted, or lost) archive logs.
Here is the "typical" scenario you need to open/recover oracle database but you do not have the archive log files - that pretty much renders your Oracle database useless except you do know that that the data is still there and there MUST be a way to open the database without the archive logs and “reset” logfiles…
Here is how to open Oracle Database without archive logs:
1. Shutdown your database. 2. Set the following parameter in your init.ora files (you might need to create pfile from spfile)
_allow_resetlogs_corruption=true 3. Mount your database and issues “alter database open resetlogs” 4. The database will attempt to open but will crash. 5. Edit your init.ora file and and perform the following:
Remove _allow_resetlogs_corruption=true entry Add undo_management=manual 6. Mount your database 7. Recover database using “recover database command” 8. Open your database – “miracle” your database will open. “alter database open” do not user “alter database open resetlogs”
BUT (It’s a big BUT) the database is not ready yet
Your UNDO tablespace is still in manual mode and the original UNDO tablespace is still corrupted.
Here is how to fix that:
1. Create new undo tablespace i.e UNDOTBS2 2. Set UNDOTBS2 as default undo tablespace 3. Remove undo_management=manual from init.ora 4. Bounce your database
Follow below step to drop your “old” tablespace:
1 – Identify the bad segment -
select segment_name, status from dba_rollback_segs where tablespace_name='undotbs_corrupt' and status = ‘NEEDS RECOVERY’;
SEGMENT_NAME STATUS ------------------------------ ---------------- _SYSSMU22$ NEEDS RECOVERY
2. Bounce the instance with the hidden parameter “_offline_rollback_segments”, specifying the bad segment name:
_OFFLINE_ROLLBACK_SEGMENTS=_SYSSMU22$
3. Bounce database, nuke the corrupt segment and tablespace: SQL> drop rollback segment "_SYSSMU22$"; Rollback segment dropped.
SQL > drop tablespace undotbs including contents and datafiles; Tablespace dropped. Now you are done …
FNDCPASS is an EBS tool to change passwords of database schema's within the Oracle EBS. For example, you can change the APPS password using FNDCPASS, but also any other schema in the EBS database. FNDCPASS can also be used to change the password of an application user (like sysadmin).
To change the APPS password use... FNDCPASS apps/*** 0 Y system/***** SYSTEM APPLSYS [new_password]
To change any other schema... FNDCPASS apps/**** 0 Y system/***** ORACLE GL [new_password]
To change the password of a application user FNDCPASS apps/*** 0 Y system/****** USER SYSADMIN [new_password]
When changing the password of all schemas in the database, you have a lot off FNDCPASS to do...there are almost 200 schemas in the EBS database that need to be changed. Default the password is schema name, so gl/gl and ap/ap...
When installing patch 4676589 (11i.ATG_PF.H Rollup 4) a new feature is added to FNDCPASS. Now you can use the ALLORACLE functionality to change all the schema passwords in one FNDCPASS.
Here is what I did to use the new FNDCPASS feature...
1. install AD: Patch 11i.AD.I.4 (patch 4712852) 2. install patch 5452096 Purging timing information for prior sessions. sqlplus -s APPS/***** @/appl/prodappl/ad/11.5.0/admin/sql/adtpurge.sql 10 1000 Spawned Process 17504 Done purging timing information for prior sessions. AutoPatch is complete. AutoPatch may have written informational messages to the file/appl/prodappl/admin/prod/log/u5452096.lgi Errors and warnings are listed in the log file/appl/prodappl/admin/prod/log/u5452096.log and in other log files in the same directory. 3. run the Technology Stack Validation Utility [oracle@ebs2 bin]$ ./txkprepatchcheck.pl -script=ValidateRollup -outfile=$APPLTMP/txkValidateRollup.html -appspass=apps *** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS ***STDOUT /appl/prodcomn/rgf/prod_ebs2/TXK/txkValidateRollup_Mon_Jan_8_stdout.log Reportfile /appl/prodcomn/temp/txkValidateRollup.html generated successfully. 4. run autoconfig 5. apply patch 4676589 (11i.ATG_PF.H Rollup 4, Applications Technology Family) 6. After the install 7. apply patch 3865683 (AD: Release 11.5.10 Products Name Patch) 8. apply patch 4583125 (Oracle XML Parser for Java) see note 271148.1
Verify if the upgrade has been successful.. cd $JAVA_TOP [oracle@ebs2 java]$ unzip -l appsborg.zip grep 9.0.4 0 04-19-03 02:10 .xdkjava_version_9.0.4.0.0_production [oracle@ebs2 java]$ if there is an xdkjava_version_9.0.4.0.0_production entry, then XML parser is installed. 9. run autoconfig 10. disable maintenance mode (via adadmin) Change Maintenance Mode ---------------------------------------- Maintenance Mode is currently: [Enabled]. Maintenance mode should normally be enabled when patchingOracle Applications and disabled when users are logged onto the system. See the Oracle Applications MaintenanceUtilities manual for more information about maintenance mode. Please select an option: 1. Enable Maintenance Mode 2. Disable Maintenance Mode 3. Return to Main Menu
Enter your choice [3] : 2 sqlplus -s &un_apps/***** @/appl/prodappl/ad/11.5.0/patch/115/sql/adsetmmd.sql DISABLE Successfully disabled Maintenance Mode.
Now try the new FNDCPASS function..
[oracle@ebs2 prod_ebs2]$ FNDCPASS apps/apps 0 Y system/manager ALLORACLE WELCOME Log filename : L2726002.log Report filename : O2726002.out [oracle@ebs2 prod_ebs2]$ [oracle@ebs2 prod_ebs2]$ sqlplus apps/apps SQL*Plus: Release 8.0.6.0.0 - Production on Mon Jan 15 08:50:39 2007 (c) Copyright 1999 Oracle Corporation. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, OLAP and Data Mining options SQL> conn gl/welcome Connected. SQL> conn ap/welcome Connected. SQL>
select lpad(' ', 2*level) || granted_role "User, his roles and privileges" from ( /* THE USERS */ select null grantee, username granted_role from dba_users where username like upper('%&enter_username%') /* THE ROLES TO ROLES RELATIONS */ union select grantee, granted_role from dba_role_privs /* THE ROLES TO PRIVILEGE RELATIONS */ union select grantee, privilege from dba_sys_privs ) start with grantee is null connect by grantee = prior granted_role; System privileges to roles and
System Privs to Users and Roles select lpad(' ', 2*level) || c "Privilege, Roles and Users" from ( /* THE PRIVILEGES */ select null p, name c from system_privilege_map where name like upper('%&enter_privliege%') /* THE ROLES TO ROLES RELATIONS */ union select granted_role p, grantee c from dba_role_privs /* THE ROLES TO PRIVILEGE RELATIONS */ union select privilege p, grantee c from dba_sys_privs ) start with p is null connect by p = prior c;
Object Privs:
select case when level = 1 then own || '.' || obj || ' (' || typ || ')' else lpad (' ', 2*(level-1)) || obj || nvl2 (typ, ' (' || typ || ')', null) end from ( /* THE OBJECTS */ select null p1, null p2, object_name obj, owner own, object_type typ from dba_objects where owner not in ('SYS', 'SYSTEM', 'WMSYS', 'SYSMAN','MDSYS','ORDSYS','XDB', 'WKSYS', 'EXFSYS', 'OLAPSYS', 'DBSNMP', 'DMSYS','CTXSYS','WK_TEST', 'ORDPLUGINS', 'OUTLN') and object_type not in ('SYNONYM', 'INDEX') /* THE OBJECT TO PRIVILEGE RELATIONS */ union select table_name p1, owner p2, grantee, grantee, privilege from dba_tab_privs /* THE ROLES TO ROLES/USERS RELATIONS */ union select granted_role p1, granted_role p2, grantee, grantee, null from dba_role_privs ) start with p1 is null and p2 is null connect by p1 = prior obj and p2 = prior own;
Apple iphone 1.1.4 update error ""Slide for Emergency".
Updating your iphone to Release 1.1.4 may lock your phone in "recovery" mode. My iphone was updated with Rel. 1.1.4, finished updating rebooted and stuck with the message "Slide for Emergency" in several languages. There is nothing you can do at this point since everything is disabled. Calling to Apple support revealed that they have no idea on how to help you in this situation, rebooting your phone is pointless at this time.
Here are the proven remedies that I compiled:
1. Switch your USB ports 2. Unistall iTunes and clean Windows registry using regedit.exe of all Apple and iTunes enties 3. Connect your iphone to a different PC (or MAC) with iTunes that will resynch and restart you iphone.
If everything fails
4. Download ZIPphone utilities from www.ziphone.org for your Release. DO NOT select to "unlock" your phone, simply go to "Advanced Features" tab and click on "Normal Mode" button. That action will exit your phone from the "recovery mode".
Good luck and remember just like with the database upgrades – always have backup.
select segment_name table_name, sum(bytes)/(1024*1024) table_size from user_extents where segment_type='TABLE' and segment_name = 'YOUR_TABLE_NAME' group by segment_name
REM Script for getting undocumented init.ora REM COLUMN parameter FORMAT a37 COLUMN description FORMAT a30 WORD_WRAPPED COLUMN "Session Value" FORMAT a10 COLUMN "Instance Value" FORMAT a10 SET LINES 100 SET PAGES 0 SPOOL _hidden_ora_params.txt SELECT a.ksppinm "Parameter", a.ksppdesc "Description", b.ksppstvl "Session Value", c.ksppstvl "Instance Value" FROM x$ksppi a, x$ksppcv b, x$ksppsv c WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm LIKE '/_%' escape '/' / SPOOL OFF SET LINES 80 PAGES 20 CLEAR COLUMNS
Cloning an Oracle home involves creating a copy of the Oracle home and then configuring it for a new environment. If you are performing multiple Oracle Database installations, then you may want to use this method to create each Oracle home, because copying files from an existing Oracle Database installation takes less time than creating a new version of them. This method is also useful if the Oracle home that you are cloning has had patches applied to it. When you clone this Oracle home, the new Oracle home will have the patch updates as well. Note: In addition to cloning an Oracle home, you can clone individual Oracle Database installations by using Enterprise Manager Database Control. Oracle Database Administrator's Guide provides detailed information about cloning Oracle Database installations and Oracle homes. To clone an Oracle home: 1. Verify that the installation of Oracle Database that you want to clone has been successful. You can do this by reviewing the installActionsdate_time.log file for the installation session, which is normally located in the /orainventory_location/logs directory. If you have installed patches, then you can check their status by running the following commands: $ $ORACLE_HOME/OPatch ORACLE_HOME=ORACLE_HOME_using_patch $ $ORACLE_HOME/OPatch opatch lsinventory
2. Stop all processes related to the Oracle home. Refer to the "Removing Oracle Software" section for more information on stopping the processes for an Oracle home. 3. Create a ZIP file with the Oracle home (but not Oracle base) directory. For example, if the source Oracle installation is in the /u01/app/oracle/product/10.2.0/db_1, then you zip the db_1 directory by using the following command: # zip -r db_1.zip /u01/app/oracle/product/10.2.0/db_1
Leave out the admin, flash_recovery_area, and oradata directories that are in the 10.2.0 directory. These directories will be created in the target installation later, when you create a new database there. 4. Copy the ZIP file to the root directory of the target computer. 5. Extract the ZIP file contents by using the following command: # unzip -d / db_1.zip
6. Repeat steps 4 and 5 for each computer where you want to clone the Oracle home, unless the Oracle home is on a shared storage device. 7. On the target computer, change directory to the unzipped Oracle home directory, and remove all the .ora (*.ora) files present in the unzipped $ORACLE_HOME/network/admin directory. 8. From the $ORACLE_HOME/oui/bin directory, run Oracle Universal Installer in clone mode for the unzipped Oracle home. Use the following syntax: $ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME="target location" ORACLE_HOME_NAME="unique_name_on node" [-responseFile full_directory_path]
For example: $ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_1" ORACLE_HOME_NAME="db_1"
The -responseFile parameter is optional. You can supply clone-time parameters on the command line or by using the response file named on the command line. Oracle Universal Installer starts, and then records the cloning actions in the cloneActionstimestamp.log file. This log file is normally located in /orainventory_location/logs directory. 9. To create a new database for the newly cloned Oracle home, run Database Configuration Assistant as follows: $ cd $ORACLE_HOME/bin $ ./dbca
10. To configure connection information for the new database, run Net Configuration Assistant. $ cd $ORACLE_HOME/bin $ ./netca
Database Management Systems (DBMS) have been with us for several decades now, significant progress has been made in DBMS software evolution, the database management software is become ever more powerful, scaling horizontally and vertically. Database software vendors such as Oracle, Sybase, IBM, Informix keep updating their software offerings with more features being added almost on daily basis. With the database computing consolidating in the hand of single company - Oracle the logical question comes to mind what is next? Will Oracle once again reinvent the database computing or fall inevitable victim of GNU software projects. We have witnessed Linux taking over server operating systems computing and slowly dissolving and assimilating away all proprietary Unix offerings (AIX, HP, Tru64….and others), the list is ever shrinking and eventually even the last big four (AIX, HP-UX, Sun, Tru64) will succumb to overwhelming power of GNU Development. Will this happened in the database world? Of course, most of us blessed with the “vision” saw the inevitability of this evolution back in early nineties with the advent of Linux. GNU databases will overpower traditional DBMS vendors in terms of scalability, costs, performance and features. Some already exist and some have not been invented yet. So who will conquer the ever powerful database vendors such as Oracle and others? The contender is already here – PostgreSQL. A distant relative of Oracle it will come back and claim the throne of database computing.
Inevitability. PostgreSQL or any other GNU/BSD database offering will not conquer proprietary database single handedly but rather though a process of “computing evolution” i.e. our perception of database and DBMS will evolve and along with propelling GNU database software to the commanding role. There are several evolutionary elements that needed to be present in order for GNU software offering become the dominant platform of choice.
1. Project vs. Product. The GNU software in our case PostgreSQL has to be a “project” and not a “product”. Seems confusing at first but bear with me here, lets compare two database offerings PostgreSQL and MySQL one is a “project” and the other is a product. MySQL is a “product” that is owned by a software company MySQL AB with available source code. “Product” can be sold, discontinues assimilated etc…Speaking of which that probably exactly what will happened to MySQL after the recent acquisition by Sun Microsystems.
Very exciting and sad news, there are a number of companies that have performed similar stunts before their agonizing demise (Novell comes to mind purchasing Word Perfect and then later SuSe). Now Sun Microsystems joined the club. Do not get me wrong here – I have been one the Sun’s biggest fans and have personally contributed to their bottom line - and I mean serious contributions here. Being a database consultant for nearly two decades I have suggested and implemented Sun hardware at a number of large sites, dealing with mostly incompetent sales reps, back and forth with configurations. Ahhhh the Sun Microsystems once the darling of Oracle DBA’s, everything seemed to work on Sun, well everything except E10000 fiasco, and E6500 processor nightmare, and…. Fine, I will not get carried away here. Sun was and still is a viable platform. I used to hold their stock, did I say used to? Yes I did. Scott is not steering Sun's ship any longer and the ship is about to run ashore. Sun fell the victims of their own success and business luck, lucky breaks – such as renaming their workstations into “internet” servers in the early nineties and then successfully jumping on the phenomenal growth of the internet, Costling’s Java escapades - the list could go on. Unfortunately a lot has changed since early nineties Firefox is again “new”, google, databases in terabytes are not “large” anymore, but Sun never changed its sales model – back and forth to the sales reps with hardware configuration, overly priced hardware and operating system, outrageous support costs, poor consulting division and not to forget ridiculous hardware offerings- “Black Box” comes to mind. I always wondered why aren’t Sun’s leaders looking at Dell? Haven’t they learned anything? Commodity Hardware – that is the end of Sun Microsystems hardware sales and failure of betting on Intel. Well you say they still have Java and Sun OS you would say, sorry folks the Sun OS will be dead with Spark architecture, and Java will outlive Sun. Things are pretty bad and now to top it all off Sun goes out and blows one billion (well only half of it in cash) for MySql. Why???!!! Simple- to speed up the its painfully slow demise. Here is the quick look in the future:
Oracle will wait for Sun to continue to loose money and soften up and then will snag Sun and MySql, the next step will be MyOracle and the end of that database. As you all know Oracle already owns the only viable MySql database storage – InnoDB.
MySql the database. MySql - the darling of developers – was never really a viable database platform, plainly SQL engine on top of text files, major features were added in Release 5, INNODB is still the only “viable” database storage for MySQL. It used to be mind boggling for me the to understand to as why so many start up companies would choose MySQL over Postrges, until I had the opportunity work as a DBA in one of them. The “Developer” attraction to MySQL is simple – you need to quickly throw a prototype of your application without worrying about security, permissions, data integrity, ACID etc … simply put all that ability that DBAs hate and developers love. Now after MAXDB is gone back to SAP AG, MySQL no longer has so-called “enterprise” grade database, I had very high hopes for MySQL cluster but they can not seem to get over physical memory/database size limitation (MySQL sells it as a “feature” of course). Developers and DBA (truly your) loved MySQL as an underdog alternative to Oracle, the “dark horse” – I liked them for that and passed their certification (very easy compared to Oracle or SQL Server). But you can hardly call Sun Microsystems an “underdog”, well may be in near future after yet another attempt at DBMS market (Sun tried to market Postgres before).
Sun Microsystems and MySQL. The answer is simple Sun is dying and in its aging brain starts making incoherent decisions – see for yourself: Sun tries to offer support for Postgres, fails at that and then buys MySQL database while supporting Greenplum’s Postgres offering and creating “database appliance” to run Greenplum Postgres, finally to make matters worse Sun unveils project “Black Box” – simply put a shipping container staffed with Sun’s hardware – truly an idiotic idea. Go make sense of that?! Well there is no common sense here just a desperate moves in the view of inevitable demise, sadly Sun is being steered by a “political” leader not a visionary, yes you can become a CEO by being “political” but sadly you cannot grow your company with the same skill set, you need a visionary. Scott you have sealed Sun’s fate by choosing your successor…
Thanks Sun for killing MySQL in your agony. But the story does not end here…
Near Future - I will assume the role of Nostradamus here:
Oracle will buy Sun and kill MySQL, Oracle will also aggressively market its own OS that will eliminate AIX, Sun OS, HP-UX and Red Hat. Oracle and Microsoft will divide the enterprise computing. Microsoft will own desktops and email, Oracle will own servers OS and the databases. But wait there more to that….
In conclusion underdog Postgres Database company (Not Greenplum) will kill Oracle, just like GNU Linux will rain supreme in OS computing….
And Apple will still fail to wrestle the desktop from Microsof, Steve Jobs will get booted from Apple (once again).
Oracle finally released so-called "small client" that can be downloaded from http://www.oracle.com/technology/tech/oci/instantclient/index.html no more Oracle "bloatware" client installation and maintenance issues. Thank you Oracle it only took you twenty years in development...
Order of StartUp of Services Should be First DB Listener, Database & then Application Tier Services
Order of ShutDown of Services Should be First Application Tier Services then Database & DB Listener
Database Startup/Shutdown Scripts Depending on your AD Version these will be in ORACLE_HOME / appsutil/scripts /SID_hostname addbctl.sh database startup shutdown script addlnctl.sh database listener Script
Where
AD is for Application DBA DB is for database DLN is database listener CTL is control
Isn't this easy to remeber ( Thanks to Oracle for naming convention)
----- Application Tier Startup/Shutdown Scripts Depending on your AD Version these will be in
OAD_TOP/admin/scripts/ SID_hostname
adalnctl.sh Apps Listener Control Script adapcctl.sh Apache/Web Server Control Script adcmctl.sh Concurrent Manager Control Script addisctl.sh Discoverer Control Script adfrmctl.sh Forms server Control Script adrepctl.sh Report Server Control Script adstpall.sh Stop All Middle/Application Tier adstrtall.sh Start All Middle/Application Tier
Where AD & CTL you already know now :) isn't it
adl stand for Apps Listener apc stand for Apache cm Concurrent Manager dis Discoverer frm forms rep report
Do you know whats Use of Apps Listener ? Check else I will post it in future post . Check what Advertisers has to say on your right side of page .
Postgres XC explained Users demand faster processing and as the processing and reports get faster so do the expectation for even faste...