Thursday, November 12, 2009

Highlevel Availability -- continue

Taking precautions against unplanned downtime

Although one cannot prevent failures, one can take all reasonable precautions. The most obvious and most important precaution to take is to put in place a well-designed and implemented backup regime, taking into account the special requirements of the application. This is a subject beyond the scope of this article but, nonetheless, it is worth emphasizing its importance. Also…

Process failure precautions

• Control access to the server and server room
• Ensure that all of your team clearly understand their roles and responsibilities.
• Implement change controls to ensure that all software and hardware changes to a production server are documented. Because Change control systems require the signoff by several team specialists it allows them to check for potential problem .
• Document and map all of your SQL Server instances, being particularly careful to record application relationships such as replication or log-shipping, data-feeds, message routes, links, remoting, and file transfer routes.
• Make sure your Test servers are identical in configuration to your Production servers.
• Before applying patches, hot fixes, and service packs, test them first on a Test Server.

Change failure precautions

• Document all proposed changes
• List the expected impact on the production system
• Gain consensus and sign off for the changes, as appropriate.
• Test the effect of the changes in terms of functionality and Stress/Load.
• Document the roll back/reversion plan and test it out on those who are likely to be 'early responders' to a system failure.
Natural, and man-made, disaster precautions
• Arrange for the service to be mirrored, or held at 'Warm stand-by', a long way away. Test out the ability to switch the service remotely. SAN replication is a popular solution, but mirroring is very effective

Hardware failure precautions

• Simulate failure in all likely places to check that secondary hardware 'kicks-in' as expected.
• Make sure there is an architecture diagram, and clear instructions for all hardware recovery routines, which are easily understandable to the 'first responder'.
• Provide generous battery-backup.
• Use redundant power supplies
• Use hardware and software monitoring tools: hardware often gives out warning signs before 'letting go'.
• Use a RAIDed array or SAN for storing your data, with hot-swappable drives with available spares. A 'Stripe of Mirrors' (Raid 10) is probably best practice.
• Install redundancy in storage controllers.
• Place the databases of your server on a different raid array to the transaction log. Locate TempDB on a high performance RAID array. SQL Server cannot function without it.
• Provide both Network card and router redundancy
• Ensure at least 'Warm Standby' fall back servers by using clustering, database mirroring, synchronization or log shipping.


Software Failure precautions

• Software failure can happen due to software changes, but also when data changes. Even date changes can cause failure. 'Code Rot' is the common term for software system failure when no recent software changes have been made.
• Use Change and source control (see change failure above)
• Before rolling out a production release, do strict 'limit' testing (testing under the extremes of data or throughput, and with hardware components randomly unplugged to assess whether software degradation is 'graceful' or not)
• Perform Regular regression testing on the test server with different simulated loads
• Avoid overlapping jobs in the SQL Server Agent; do routine DBCC checks and re-indexes of tables at off-peak times.

Network Failure precautions

TCP/IP is designed fundamentally as a resilient system in the event of disaster, but this relies on the network infrastructure being able to route network packets via alternative pathways in the event of the failure of a pathway.

• Secondary DNS/WINS servers must be provided.
• The system must not be reliant on a single domain server or active directory.
• There should be Redundant routers/switches
• Redundant WAN/Internet connections are generally important.
• Ensure that there is no single point of failure in the network by regular 'limit-testing'

Security Failure precautions

• Ensure the physical security of each SQL Server.
• Create alerts and reports for any unusual patterns of user activity on the server, and investigate them (SQL Data Compare is very handy for this)
• Give users the fewest permissions they need to perform their job.
• Audit all login and logout events
• Use DDL triggers to log and notify all changes to the security configuration of the server.
• Adopt all current security best-practices when implementing the Server

Tuesday, November 3, 2009

Overview of Highlevel Availability

Why High Availability?

Mission critical computer systems need to be available 24 hours a day, 7 days a week, and 365 days a year.

When this system and the applications are not available, due to technical problems, we suffer loss of productivity at work and inconvenience in our personal lives. It is not difficult to calculate the real costs incurred when critical business systems are down.
More serious consequences occur when critical systems such as traffic control, medical life support, or Health services systems are not functioning.

When an application becomes unavailable, the work that it was doing simply stops.
At best, such an outage simply results in lost productivity - the application will be up and running some time later, and the work will be completed later. More serious consequences can occur through safety, legal actions, fines or simply negative publicity.
The impact of downtime will vary from business to business and within a business from application to application.

Availability, High Availability, and Fault Tolerance: What do these terms mean?

Availability is the percentage of time that a system operates during its intended duty cycle. For example, if a given system is expected to be functional for 8 hours per day, then availability is measured as a percentage of those eight hours. If a system is non-functional outside this period, it is not counted against the “Availability Metric.”

High Availability
attempts to specify an amount of time as a percentage of the intended duty cycle that a system must be functional. For example, if we specify availability metric as “Five Nines,” it is understood to mean that the system should be functional for 99.999% of the desired duty cycle.
Refer to the following table for examples of various levels of availability and associated allowable downtime per year/month/week assuming a 24 hour per day duty cycle.

Availability % Downtime / year Downtime / month(30 days) Downtime / week
99.9% ("three nines") 8.76 hours 43.2 minutes 10.1 minutes

99.99% ("four nines") 52.6 minutes 4.32 minutes 1.01 minutes
99.999% ("five nines") 5.26 minutes 25.9 seconds 6.05 seconds


There are two main hardware concerns with respect to maintaining a highly available database environment: server high availability and storage availability.

Fault tolerance (Data redundancy in DB)
differs from high availability by providing additional resources that allow an application to continue functioning after a component failure without interruption. Many of the high-availability solutions on the market today actually provide fault tolerance for a particular application component. Disk mirroring, where there are two disk drives with identical copies of the data, is an example of a fault-tolerant component. If one of the disk drives fail, there is another copy of the data that is instantly available so the application can continue execution.

High Availability (HA) solution


High Availability (HA) solution must address both unplanned and planned causes of downtime to achieve a truly fault tolerant and resilient IT infrastructure.

Causes of Planned down time

Repair and upgrades that have minimal impact on the business are considered maintenance. For many applications, availability during business hours is required, but some downtime during non-business hours is acceptable.

All systems will require maintenance at some point. If management does not plan for system maintenance, the system will pick the time and duration for an outage! It is up to the system designer to understand the business need and design the system to allow for planned downtime, therefore minimizing the risk of a system failure.

Causes of Unplanned down time


 * Hardware failure
   -->Server hardware
   --> Storage hardware
 * Human error
  -->System management toll
  -->Staff training
  -->Process oriented IT organization
 * Software corruption or bug
 * Viruses
 * Natural disaster

Tuesday, October 13, 2009

Convert ROWS into COLUMN

convert database Rows into Column its easy and simple.

If you have a table "master_stu" its having values like

stu_id stu_name class percentage
==== ====== === =======
1 vin sslc 88
1 vin hsc 90
2 swin sslc 75
2 swin hsc 89

you want to display above table into

stu_id stu_name class percentage class percentage
==== ====== === ======= === ========
1 vin sslc 88 hsc 90
2 swin sslc 75 hsc 89

just write a query like

select
tbl1.stu_id as stu_id, tbl1.stu_name,tbl1.class as class,tbl1.percentage as percentage,tbl2.class as class,tbl2.percentage as percentage
from
(select * from master_stu where class = 'sslc') as tbl1,
(select * from master_stu where class = 'hsc') as tbl2,
where
tbl1.stu_id=tbl2.stu_id

any query's mail me!

Saturday, October 3, 2009

PostgreSQL Technical Features

Why use PostgreSQL?

* It doesn't cost money.
* Speed about the same factor as commercial databases.
* Supports a broader subset of SQL than MySQL.
* Supports transactions.
* Supports large tables that exceed Linux' file limit.
* Fully Programmable.


Technical Features

* Fully ACID compliant.
* ANSI SQL compliant.
* Referential Integrity.
* Replication (non-commercial and commercial solutions) allowing the duplication of the master database to multiple slave machines.
* Native interfaces for ODBC, JDBC, .Net, C, C++, PHP, Perl, TCL, ECPG, Python, and Ruby.
*Rules.
* Views.
* Triggers.
* Unicode.
* Sequences.
* Inheritance.
* Outer Joins.
* Sub-selects.
* An open API.
* Stored Procedures.
* Native SSL support.
* Procedural languages.
* Hot stand-by (commercial solutions).
* Better than row-level locking.
* Functional and Partial indexes.
* Native Kerberos authentication.
* Support for UNION, UNION ALL and EXCEPT queries.
* Loadable extensions offering SHA1, MD5, XML, and other functionality.
* Tools for generating portable SQL to share with other SQL-compliant systems.
* Extensible data type system providing for custom, user-defined datatypes and rapid development of new datatypes.
* Cross-database compatibility functions for easing the transition from other, less SQL-compliant RDBMS.

Friday, October 2, 2009

Installing PostgreSQL on BOSS

This tutorial is about how to installing PostgreSQL on BOSS( Bharat Operating System Solutions) Server.

just 3 step to install and remote system access to the database server

1) Install PostgreSQL
2) Change authentication method
3) Restart PostgreSQL Server

kindly go through step by step,

1) Install PostgreSQL

apt-get install postgresql

2) Change authentication method

By default, PostgreSQL database server remote access disabled for security reasons.
We need to edit file pg_hba.conf and postgresql.conf to change authentification method for accessing PostgreSQL database.


I) add IP address of the system to access the database server

vi /etc/postgresql/8.2/main/pg_hba.conf


--Append the following configuration lines to give access to 10.10.29.0/24 network:
(TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD)
host all all 10.10.29.0/24 255.255.255.0 trust

--Append the following configuration lines to give access to 192.175.45.56 system:
host all all 192.175.45.56 255.255.255.0 trust

Save and close the file.

II) If you are using PostgreSQL version 8.x or newer use the following instructions or skip to Step III for older version (7.x or older).

vi /etc/postgresql/8.2/main/postgres.conf

defaults to 'localhost', and '*' is all ip address,
Find configuration line that read as follows:
listen_addresses='localhost'
changed into like below
listen_addresses='*'

Or just bind to 202.54.1.2 and 202.54.1.3 IP address
listen_addresses='202.54.1.2, 202.54.1.3'


III) Information for old version 7.x or older

Following configuration only required for PostgreSQL version 7.x or older. Open config file, enter:
vi /etc/postgresql/8.2/main/postgres.conf

Bind and open TCP/IP port by setting tcpip_socket to true. Set / modify tcpip_socket to true:
tcpip_socket = true

Save and close the file.

3) Restart PostgreSQL Server

Type the following command:

/etc/init.d/postgresql restart

any query's mail me!

Delete duplicate rows in PostgreSQL

The basic assumptions are that you have a table, named "emp_exp", that contains a int field, called emp_id and that the emp_id field may contain duplicate rows.

having table "emp_exp", it contain rows like

emp_id organization
------- -------------
1567 POSTGRES
1567 ORACLE
2089 WEBRAIN
2089 IBM

1) First, as always, backup your database.
2) Create a unique id (i.e. like a primary key) for each row, if one does not exist. else follow the step 3, use your unique column in where clause and select clause of sub-query in step 3

I) CREATE SEQUENCE emp_sequence
INCREMENT 1 MINVALUE 1 MAXVALUE 1999999 START 1 CACHE 1;

-- add new column to the table and Populate the field
II) ALTER TABLE emp_exp ADD COLUMN id integer;
III) UPDATE emp_exp SET id = nextval('emp_sequence');

-- after above step your table look like (You have added id column)

id emp_id organization
-- ------- -------------
1 1567 POSTGRES
2 1567 ORACLE
3 2089 WEBRAIN
4 2089 IBM



--NOTE before delete row in your table, if you want to know no.of duplicate rows in your table kindly follow step 4

3) Delete the duplicates

I) DELETE FROM emp_exp
WHERE id IN (SELECT max(id)
FROM emp_exp
GROUP BY emp_id HAVING count(*) > 1)

---same query can be re-write like (OR)

I) DELETE FROM emp_exp
WHERE id NOT IN (SELECT min(id)
FROM emp_exp
GROUP BY emp_id HAVING count(*) >= 1)


now your table emp_exp, have only unique emp_id value



4) Estimate the number of duplicates

You can use the query below to estimate the number of duplicates, so that once the deletion takes place you can figure out if something has gone horribly wrong.

SELECT sum(dupes.c) - count(dupes.c)
FROM (SELECT count(*) AS c
FROM emp_exp
GROUP BY emp_id
HAVING count(*) > 1
) AS dupes


Delete the duplicate records from table in postgresql

DELETE FROM emp_exp
WHERE ctid NOT IN (SELECT min(ctid) FROM emp_exp GROUP BY username)

CTID : It uniquely identifies row in a table and it refer the physical location of the records in table.

Friday, September 11, 2009

send free SMS without registration

send sms without registration is not possible at all by these days

DON'T SPEND YOUR TIME for searching this.

here I'm listing out some of the site from there you can register and start send sms to all over India,Gulf countries and world.

www.160by2.com/
www.sendsmsnow.com/
www.way2sms.com/
www.sendgroupsms.com/
www.mtnsms.com/
www.sendsms.com/
www.freebiesms.co.uk/
www.text4free.net/

and many more...

Saturday, August 8, 2009

Java hot links

Java™ references
Sun Site - Thebest place for Java news.
Alphaworks - IBMRessources.
Java World - IDG's magazine.
Java.net - Java community.
JavaLobby - Huge Forum.
Jars - Many Ressources & Applets.
Java Developer's Journal - High quality articles.
FreshMeat - Java open source projects and more.
jGuru - Best place for Java FAQ.
ONJava - O'Reilly Java Network.

Applets

Java Boutique - Huge Applets Collection.
JavaPowered - Applets Collection
WalterFendt - Best place for educational Applets.
OpenCube - Applets Packages.
Java Bookmark- Java Ressources list.
FreewareJava - Free Applets Collection.
JavaShareware - Nice site, many updates.
Equinox - Nice FX applets.

Java libraries
Java Numerics - Maths, Matrix, ...
VisualNumerics - Extended maths functions.
Java & MP3 - Our Mpeg Audio links.
JavaSound - Our Audio links.

Servlets/JSP

Codango - Many JSP and Java ressources.
JavaRanch -Forums about Java.
Jakarta - Apache Jakarta (Java) project.
JavaSkyline - Java Portal.



J2EE™

Java Reference - Best place for J2EE.
TheServerSide - Articles and Reviews.
Resin - Fast Servlets/JSP Engine.
Tomcat - Open source Servlets/JSP Engine.
JBOSS - OpenSource AppServer.
JOnAS - Another OpenSource AppServer.
Intalio- OpenSource BPMS.
WebLogic- BEA AppServer.
WebSphere - IBM AppServer.
Oracle AS - Oracle AppServer.
JavaDigest - Useful Java/J2EE articles.

XML

Xml.com- Good best place to start.
XMLPortal - Many info there.

Tuesday, August 4, 2009

Terms to search more information about market

Free stock recommendations
buy sell stock signals
BSE, NSE, trading tips
stock market indicators
advice stock market investing
day trading
Free day trading stock pick
education stock trading
Free India share tips
online share trading
free stock market graphs
stock market trend
day trading
daytrading software
daytrading stocks
daytrading tips
day trading made easy
daytrading university
day trading system
day trading stocks
daytrading rules
learn day trading
online daytrading
earn money online
high return investment
high yield investment
investment advice
investment growth
investment information
investment opportunities
investment securities
investment strategy
long term trading
shares investment
stock investment
stock market investment
share market trading
stock market chart
free technical analysis software
market prediction
day trading stock
stock market tools
Free stock market trading tips
stock day trading software
Free day trading techniques
technical analysis stock
nse bse techniques
stock software