Enabling ARCHIVELOG Mode

The following steps will guide you to enable archivelog Mode.

1. Check the current archivelog mode.
 
SELECT LOG_MODE FROM V$DATABASE

2. SHUTDOWN AND RESTART YOUR DATABASE TO MOUNT STATE.
 
SHUTDOWN IMMEDIATE


STARTUP MOUNT

3. ENABLE ARCHIVE MODE

ALTER DATABASE ARCHIVELOG.

4. OPEN YOUR DATABASE.

ALTER DATABASE OPEN

Introduction to Linux Security

There is a saying in the security world that the only truly safe computer system is one that is disconnected from the network, switched off and buried six feet under ground. The sentiment may be somewhat true but it is hardly a practical solution to the problems we face today in protecting servers and desktops from outside intrusion.

There are more computer systems connected to the internet either directly or via local area networks than at any time in the history of technology and the numbers are growing at a rapid rate. It seems that not a month goes by without another story in the news about the internal network of a major corporation being compromised by an intruder. 

The simple fact is that there really is no such thing as a truly secure system as long is it is connected to a network. If the large corporations with expensive firewalls and talented IT staff can’t always stop criminals from breaking in what chance do the rest of us have?

Fortunately all is not lost and we do not have to pull the network cables out of the back of our computer systems. With careful planning and system configuration it is quite possible to create a secure environment that will cause the hacker to move on to the next, easier target without rendering the entire system useless. 

Introduction to Computer Security

What is computer security?

Security is risk management. - unknown

"A computer is secure if you can depend on it and it's software to behave as you expect" - Practical UNIX and Internet Security

Security is: availability, consistency, access control, data confidentiality, authentication. - http://www.sun.com/security/overview.html

"The principal objective of computer security is to protect and assure the confidentiality, integrity, and availability of automated information systems and the data they contain." - http://csrc.nist.gov/publications/secpubs/cslaw.txt

There are numerous definitions for "computer security", and most of them are correct. Essentially computer security means enforcement of usage policies, this must be done since people and software have flaws that can result in accidents, but also because someone may want to steal your information, use your resources inappropriately or simply deny you the use of your resources.

Security Policy

A security policy is an expression of your organizations security goals. Security goals will vary greatly by organization, for example a software vendor is typically more concerned about the confidentiality and integrity of their source code anything else, while a pornographic website is probably more concerned about processing credit cards online. There is an immense amount of security technology available, from software and hardware to specific techniques and implementations. You cannot properly implement the technology without a solid idea of what your goals are. Do home users connecting to the office need to use VPN software? If your security policy states that all file and print transfers must either be encrypted or sent across a "trusted" network then the answer is probably yes. What authentication methods are acceptable for services that can be reached from the Internet? Do you require strong passwords, tokens, biometric authentication, or some combination? The data you collect from remote sites, is it more important that this data is collected, or is it more important that this data remain secret? Data that is remote weather telemetry is probably not as sensitive as credit card numbers.

Some security policies will need to be exceptionally broad and general, for example the security policy for JANET, the academic backbone network for England states:

Monitoring and Enforcement

19. It follows from the policy of cascaded responsibility backed up by written site agreements, that there must be some method for UKERNA to enforce the possible disconnection envisaged by the AUP, and to provide full access and assistance to law enforcement agencies where necessary.
20. The JANET-CERT has therefore been given the responsibility (in conjunction with UKERNA) to

• Monitor use of the network, as far as is possible while respecting privacy, either in response to information about a specific threat, or generally because of a perceived situation
• Require a primary site, through its nominated contact, to rectify any omission in its duty of responsibility
• Where a site is unable or unwilling to co-operate, report the issue to UKERNA and initiate the procedure for achieving an emergency disconnection
• Obtain evidence and pass on information as necessary in order to assist an investigation by a law enforcement agency
• Provide support and co-ordination for investigations into breaches of security

On the other hand a security policiy can be fine grained:

All internal email must be encrypted with PGP or GnuPG using a key of at least 1024 bits that is signed by an authorized signing entity.

Generally speaking the more detailed and technology oriented a security policy is the harder it will be to follow and keep up to date. The actuall technical details of implementing a security policy should be seperated from it. Keeping a seperate set of best practices or an actually "implementation of security policy" document is a better idea then rolling it all into the security policy.

Acceptable Use Policy

Another component of computer security is an AUP (Acceptable Use Policy). This is a document that sates what a user of your resources may or may not do with them. Typically it is part of a contract and is signed at the time when the services are purchased. Many acceptable use policies generally forbid actions that are illegal, potentially annoying to other people (and hence likely to cause problems for the provider inthe form of complaints) or are controversial (such as pornography). Other standard clauses include "this notice may change at any time without warning" and "we can terminate your service (or fire you) at any time without warning if you violate this policy. Generally speaking the majority of AUP's are reasonable and will not be a problem for normal users. These are a good compliment to a security policy as they set out in concret terms what a user is or is not allowed to do, and as they are often part of a contract it allows a provider to enforce their security policy when a user attempts to violate it or has violated it.

Privacy Policy

Privacy policies are interesting in that they are supposed to prevent an organization 9typically a company) from violating some aspects of a user's security (specifically the confidentiality of their information). Unfortunately the majority of privacy policies contain clauses like "this policy may change at any time without warning" or are simply discarded when a company decides to profit off of a user's information (such as name, address, credit card details, purchase history, etc.).

Security is a process

You only need to make one mistake or leave one flaw available for an attacker to get in. This of course means that most sites will eventually be broken into. Witness the effects of Code Red, an Nimda, both of which were hugely succesful exploiting well known and long solved vulnerabilities in the Microsoft IIS server. Regularily apply patches (after testing them). Regularly scan your network for open ports. Regularly scan your servers with intrusion testing software such as Nessus. Audit file permissions and make sure there are no unexpected setuid or setgid binaries.

Defense in depth

All technical security measures will eventually fail or be vulnerable to an attacker. This is why you must have multiple layers of protection. Firewalls are not enough, you may accidently forget a rule or leave yourself exposed while reinitializing a ruleset, use tcp_wrappers to restrict access to services as well where possible. Restrict which users can access these services, especially if only a few users need access. Encrypt traffic where possible so that attackers cannot easily snoop usernames and passwords or hijack sessions. Since security measures will fail you also need a strong audit and logging process so that you can later find out what went wrong and how bad it is.

Technical problems

These are just a handful of thousands of specific technical problems facing security administrators.

Network Connectivity

One of the biggest security challenges is the increase in network connectivity. If you have a machine that is not connected to any other machines an attacker will generally need to gain physical access. This of course greatly narrows down the number of attackers. However with everything connected to the Internet there are over 100 million people that can potentially get into your machine.

Insecure defaults

This is one of the problems that has caused no end of security problems since day one. Vendors typically ship their operating systems with insecure defaults (i.e. finger, telnet, ftp, etc.) meaning that administrators must expend a lot of effort to close security problems before they can even start to pro-actively secure their systems and networks.

Legitimate access vs. a break in

Because you must grant legitimate users access to resources there is always the potential for attackers to gain access. Attacker can guess authentication credentials (i.e. weak passwords), steal them (password sniffing), exploit flaws in the server itself and so on.

Minimizing access and privilege

When possible restrict access. If you do not need to run fingerd turn it off and remove it. An attacker cannot exploit fingerd if it isn't present. Keep users off of servers if possible, if they need shell accounts for some reason setup a separate system and partition it off from the rest of your network. Lock down workstations where possible, set BIOS passwords, secure the boot sequence, do not give them administrative access.

10 Tips for Technology Proposal-Writers

Sun Associates collaborates with school districts and state education agencies to write educational technology funding proposals, and to implement funded activities, including professional development and evaluation. We have found that successful funding proposals have several things in common. We invite you to share these 10 tips with your colleagues, and use them as a starting point for your next grant-planning meeting.

1. Read the Request for Proposals (RFP)

The number one rule for writing a successful grant is to read the RFP...and then to follow the RFP's rules and guidelines when writing your proposal. Not surprisingly, most unsuccessful proposals violate this basic rule. The RFP is written for the specific purpose of providing prospective grantees with all of the information that they need to write a successful proposal. Most grant-makers spend a huge amount of time writing their RFP. They expect you to read it and follow it carefully.

2. Write Appropriate Proposals

This follows from reading (and understanding) the RFP. Do not waste your time, or the reviewers' time by submitting proposals that do not meet the guidelines of the RFP. If an RFP says that it will not fund proposals for specific items, expenditure categories, or for specific populations, then do not write a proposal asking for these things. For example, it is quite common for grant-makers to state that they will not provide funds for hardware and software. If this is the case with your RFP, then do not write a proposal asking for funds for hardware and software. Grant-makers follow their own rules to the letter, and "exceptions" are not made. Rather, inappropriate proposals are almost always simply rejected. 

3. Follow the Structure Provided by the RFP

Another thing that virtually all RFPs provide is a "suggested" proposal structure or table of contents. If your RFP provides such a structure, follow it! Most of the time, this suggested structure forms the basis of the checklist that reviewers will use when reading your proposal. Reviewers use a checklist to determine if each proposal has all of the required elements, sections, etc. Make their job easier, and thereby improve the chances that they will like your proposal; organize your proposal by their structure. 

4. Clearly State Your Proposal's Goals

All reviewers want to see your proposed project's goals. If you do not clearly state these goals, then the assumption will be that you do not have goals. Goal-less proposals are generally not funded. Furthermore, it is important that your goals be aligned with the purposes of the grant program (as stated in the RFP) and that they are reasonable given the scope of your proposed project and resources. Good goals are at the core of all good proposals.

5. Align Your Proposal with Your Technology Planning Goals 

Good goals are also at the core of good educational technology plans. Therefore, when writing technology proposals, you should reference your planning goals. Show how your proposal supports your broader goals and how it completes some element (albeit a possibly small element) of your technology plan. Alignment with planning goals gives your proposal a "big picture" that demonstrates that the funds you are requesting will accomplish much more good than the specific, anticipated, outcomes from the proposed project. 

This is also a good place to mention that increasingly, technology proposals that come from districts which do not have technology plans are not funded. Funders expect grantwriters to have their proposals grounded in the long-term vision and strategies expressed in a technology plan. While it is not often necessary to include your technology plan with your proposal, it is always a good idea (or in fact, often a requirement) to reference it in your proposal and/or include it as an appendix.

6. Specifically State Your Project's Impact on Teaching and Learning

What impact will your proposal have on teaching and learning? This is the bottom line of any successful technology proposal. If you cannot show impact, it is unlikely that your proposal will receive funding. Do not make the reviewers search for your anticipated impact. Do not assume that they will understand your impact unless you specify it. Specifically state how your project will positively impact students and their educational environment. 

7. Include Evaluation and Dissemination Components

In many cases, an RFP will dictate that you include one or both of these components. Funders see the projects they fund as learning experiences for a larger educational constituency and as guides for future funding inititiatives they might make. Therefore, funders are interested in projects that can measure their success, document their challenges, identify potential problems, and ask questions for future research. This is the value of an evaluation component to your project. Further, virtually all funders seek ways to share the outcomes and learnings of their projects. This is the point of a dissemination component. 

It is a common mistake for proposal writers to consider evaluation and dissemination as "wastes" of often-tight project funds. Do not fall into this trap. Evaluation and dissemination components are critical to successful projects. Conscientious proposal writers, who have a "big picture" for their project, devote sufficient project time and resources to evaluation and dissemination. Even when the RFP does not specifically ask for one of these components, their inclusion very much strengthens a proposal.

8. Realize that Not All Technology-Related RFPs Fund "Computers" 

In fact, most grant programs do not fund basic hardware, software, network access, and other "infrastructure" needs. Rather, the majority of technology-related grant programs now fund staff development and curriculum development. Writing a proposal for one of these programs requires a through understanding of not only what you will use, but how and why you will use it. Another way of putting this is that few funders simply want to "give you stuff." Instead, they are mostly interested in how you are putting "stuff" to good use and creating positive impacts on teaching and learning.

9. Collaborate!

Successful proposals are collaboratively written. Collaboration not only helps in terms of editing and reviewing drafts, but more importantly it expands the ideas in your proposal. Proposals that are obviously "one person's idea" are not favorably reviewed. Further, proposals that involve several collaborating partners are always more successful than those which are limited to a single organization/school/individual. Collaboration shows that others believe in your proposal's idea and will work to make it a reality. 

10. Write, Modify, Resubmit

Few proposals are successful the first time around. If your proposed project is rejected by a funder, try again. Try with a different funder and if possible, resubmit the proposal to the original grant maker. Before you resubmit an idea, it is wise to incorporate any feedback you received on your rejected proposal. Remember, when resubmitting a proposal it is necessary to redraft the proposal document to the new RFP (in terms of organization, components, budget requirements, etc.). Do not simply photocopy your old proposal for the new submission and do not submit proposals that do not fully fulfill the current RFP.

NICE ARTICLE ON REDO LOG

In the Oracle RDBMS environment, redo logs comprise files in a proprietary format which log a history of all changes made to the database. Each redo log file consists of redo records. A redo record, also called a redo entry, holds a group of Change vectors, each of which describes or represents a change made to a single block in the database.

For example, if a user UPDATEs a salary-value in a table containing employee-related data, the DBMS generates a redo record containing change-vectors that describe changes to the data segment block for the table. And if the user then COMMITs the update, Oracle generates another redo record and assigns the change a "system change number" (SCN).

Whenever something is changed on a datafile, Oracle records it in the redo log. The name redo log indicates its purpose: When the database crashes, oracle can redo all changes on datafiles which will take the database data back to the state it was when the last redo record was written. Use v$log, v$logfile, v$log_history and v$thread to find information about the redo log of your database. Each redo log file belongs to exactly one group (of which at least two must exist). Exactly one of these groups is the CURRENT group (can be queried using the column status of v$log). Oracle uses that current group to write the redo log entries. When the group is full, a log switch occurs, making another group the current one. Each log switch causes checkpoint, however, the converse is not true: a checkpoint does not cause a redo log switch. You can also manually cause a redo log switch: alter system switch logfile.

Tuning the Oracle Shared Pool

I hope you now understand that the old "just increase the shared pool" answer isn't good enough anymore when it comes to tuning problems. You must take an in depth look at your shared pool and tune what needs to be tuned, not just throw memory at a problem until it submerges. Indeed, I have shown that in some cases increasing the size of the shared pool may harm performance and decreasing the size may be advisable.  The shared pool is vital to the proper performance of your Oracle database, you must have it properly tuned or drown in bad performance. Next we will cover what to pin, the shared pool and multi-threaded server, hashing and generalized library and dictionary cache tuning. We have also discussed ways to monitor for what objects should be pinned, discussed multi-threaded server, looked at hashing problems and their resolution as well as examined classic library and data dictionary cache tuning. We have established 8 guidelines for tuning the Oracle shared pool:

Guideline 1: If gross usage of the shared pool in a non-ad-hoc environment exceeds 95% (rises to 95% or greater and stays there) establish a shared pool size large enough to hold the fixed size portions, pin reusable packages and procedures. Gradually increase shared pool by 20% increments until usage drops below 90% on the average.

Guideline 2: If the shared pool shows a mixed ad-hoc and reuse environment, establish a shared pool size large enough to hold the fixed size portions, pin reusable packages and establish a comfort level above this required level of pool fill. Establish a routine flush cycle to filter non-reusable code from the pool.

Guideline 3: If the shared pool shows that no reusable SQL is being used establish a shared pool large enough to hold the fixed size portions plus a few megabytes (usually not more than 40) and allow the shared pool modified least recently used (LRU) algorithm to manage the pool. (also see guideline 8)

Guideline 4: Determine usage patterns of packages, procedures, functions and cursors and pin those that are frequently used.

Guideline 5: In Oracle7when using MTS increase the shared pool size to accommodate MTS messaging and queuing as well as UGA requirements. In Oracle8 use the Large Pool to prevent MTS from effecting the shared pool areas.

Guideline 6: Use bind variables, PL/SQL (procedures or functions) and views to reduce the size of large SQL statements to prevent hashing problems.

Guideline 7: In a system where there is no flushing increase the shared pool size in 20% increments to reduce reloads and invalidations and increase object cache hit ratios.

Guideline 8: In any shared pool, if the overall data dictionary cache miss ratio exceeds 1 percent, increase the size of the shared pool.

Using these guidelines and the scripts and techniques covered in this lesson, your should be well on the way towards a well tuned and well performing shared pool.

By Oracle Tips by Burleson Consulting

The Top 10 Business Plan Mistakes

It’s been nearly seven years since I posted Top 10 Business Plan Mistakes on this site. Looking back and reading the post again today, I think the list holds up very well. Still, I can’t resist making a few changes. So here is my revised version for 2012, incorporating what I wrote back then that still holds true.

1. Misunderstanding the purpose: It’s the planning that matters, not just the document. You engage in planning your business because planning becomes management. Planning is a process of setting goals and establishing specific measures of progress, then tracking your progress and following up with course corrections. The plan itself is just the first step; it is reviewed and revised often. Don’t even print it unless you absolutely have to. Leave it on a digital network instead.

2. Doing it in one big push; do it in pieces and steps. The plan is a set of connected modules, like blocks. Start anywhere and get going. Do the part that interests you most, or the part that provides the most immediate benefit. That might be strategy, concepts, target markets, business offerings, projections, mantra, vision, whatever. . . just get going.

3. Finishing your plan. If your plan is done, then your business is done. That most recent version is just a snapshot of what the plan was then. It should always be alive and changing to reflect changing assumptions.

4. Hiding your plan from your team. It’s a management tool. Use common sense about what you share with everybody on your team, keeping some information, such as individual salaries, confidential. But do share the goals and measurements, using the planning to build team spirit and peer collaboration. That doesn’t mean sharing the plan with outsiders, except when you have to, such as when you’re seeking capital.

5. Confusing cash with profits. There's a huge difference between the two. Waiting for customers to pay can cripple your financial situation without affecting your profits. Loading your inventory absorbs money without changing profits. Profits are an accounting concept; cash is money in the bank. You don't pay your bills with profits.

6. Diluting your priorities. A plan that stresses three or four priorities is a plan with focus and power. People can understand three or four main points. A plan that lists 20 priorities doesn't really have any.

7. Overvaluing the business idea. What gives an idea value isn’t the idea itself but the business that's built on it. It takes employees showing up every morning, phone calls being answered, products being built, ordered and shipped, services being rendered, and customers paying their bills to make an idea a business. Either write a business plan that shows you building a business around that great idea, or forget it. An idea alone does not a great business make.

8. Fudging the details in the first 12 months. By details, I mean your financials, milestones, responsibilities and deadlines. Cash flow is most important, but you also need lots of details when it comes to assigning tasks to people, setting dates, and specifying what's supposed to happen and who's supposed to make it happen. These details really matter. A business plan is wasted without them.

9. Sweating the details for the later years. This is about planning, not accounting. As important as monthly details are in the beginning, they become a waste of time later on. How can you project monthly cash flow three years from now when your sales forecast is so uncertain? Sure, you can plan in five, 10 or even 20-year horizons in the major conceptual text, but you can't plan in monthly detail past the first year. Nobody expects it, and nobody believes it.

10. Making absurd forecasts. Nobody believes absurdly high “hockey stick” sales projections. And forecasting unusually high profitability usually means you don’t have a realistic understanding of expenses.

By TIM BERRY

PCTFREE property for tables and indexes

Why databases aren’t really fast

When most Oracle databases are inspected to see exactly what they are doing, most often it is disk I/O access. Databases read and write a lot of data, and because magnetic drive technology is slow, often the database spends a majority of its time waiting for disk read/write requests to complete.

How Oracle manages data

The main way that Oracle manages data (in datafiles), is using blocks. Each block is read, and is written, as a single object; Oracle does not read or write partial blocks. This means that if a tablespace’s block size is set at 8k (8192 bytes), whenever information is required to be read or written, it will do it in a number of 8k chunks.

The PCTFREE property of a segment

There is a property of a table or index that can be set, that will force Oracle to pack more rows into each block. This can have a very dramatic affect on the throughput of read and write requests, because if more rows of data are packed into each block, the database requires fewer read requests to satisfy the requirements of a query.

Oracle has provided a way to control how full a block becomes before it starts to use a new block to store rows of data; this is called thePCTFREE parameter. You can see the current value for tables by inspecting dba_tables.pct_free, or dba_indexes.pct_free. ThePCTFREE parameter is set at table creation time, which will affect all rows inserted or changed in that table. If a given table/index’sPCTFREE parameter is changed after it’s creation, no existing blocks are changed, so the existing data in the table is not packed tighter.

By default, Oracle uses a value of 10 for PCTFREE. This means that it will add data to a block until it is 90% full; after this it will create a new block to hold information. If you set PCTFREE to 1, then Oracle will fill up blocks to 99% full, before using another block; This allows you to store more data in fewer blocks. If you set PCTFREE to 99, then Oracle will fill up blocks to 1% full before using another block. Usually this has the general effect of causing each row to go into a single block.

Using a low PCTFREE

Low PCTFREE effects for reads

For reads, especially scans (including full table scans), it almost always will reduce the amount of physical reads required to satisfy a read-only query (ie a select SQL statement).

Low PCTFREE for data changes

However, for row updates, this can really hurt performance, because if a field is changed in a row (via an update statement), and this requires a larger row size than is free in an existing block, then the database needs to ’split’ the row among 2 or more blocks. This is called ‘row chaining’, and can definitely affect performance adversely when those rows are read, as >1 block will need to be retrieved.

For inserts, having a low PCTFREE will cause them to go faster, as more rows will be inserted for each block written.

Note that if an index is built with a low pctfree, it may take longer for the index to be updated when corresponding rows are updated.

Low PCTFREE applications

The ideal place to use a very low value for PCTFREE include:

• Log tables that are never updated (only inserts, and deletes in rough order of inserts)
• auditing tables which should never be updated,
• Tables used to support Data warehouses, esp if rows are not updated,

Table examples where you probably should not use a very low value for PCTFREE include:

• Tables where the rowsize expands over the life of a row via many updates,
• Tables that have a lot of active transactions going against them,
• Tables where inserts and deletes happen that are not in the order of inserts
• Tables which have lots of updates in general.

Using a high PCTFREE

Above the discussion has been about having a particularly low value for PCTFREE. There are cases where a higher than default value forPCTFREE is recommended. If it is known that a rowsize will be very small upon the 1st insert, and then updated a lot (say to swell from 20 bytes to 16k bytes), and especially if the table had a high transaction rate, then forcing Oracle to store fewer rows (upon insert) will really minimize row chaining. If a table will be updating an in-row (B/C)LOB (again increasing row-length) having a low value for PCTFREE again would increase performance.

Conclusion

If you’re interested in changing your PCTFREE, try to of course test it first in a development or QA environment. The default value (10) is for many cases quite satisfactory. Using the wrong one can really hurt performance, and sometimes this happens a long time after rows are inserted.

By Jay Stanley, Sr. Staff Consultant

Senior Data Manager is needed

Qualifications

• A minimum of first degree in database development and management of data systems is a requirement

• Additional training in statistics or public health will be an added advantage

• A minimum of 5 yrs experience in working at a management level position for data systems especially in HIV care and treatment setting demonstrated data analysis (in what software package ) and report writing skills

• At least 3 yrs experience in middle level management skills and in staff supervision staff

Application Instructions:

Interested applicants should send their CV, Cover Letter, and 3 references to the Email Link above or by post to

Human Resource Manager
P O BOX 79810
Dar es Salaam, Tanzania 

Set a wait time for DDL Lock

alter session set ddl_lock_timeout = t;

Pré-requis pour Installer Oracle 11g sous Linux

Vérifier la mémoire (1Go nécessaire)
[oracle@dsiege103829 oracle]$ grep MemTotal /proc/meminfo
MemTotal: 1024364 kB

Déterminer la taille du Swap
grep SwapTotal /proc/meminfo
[oracle@dsiege103829 oracle]$ grep SwapTotal /proc/meminfo
SwapTotal: 1048568 kB

Déterminer la mémoire partagé
[oracle@dsiege103829 oracle]$ df -k /dev/shm/
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 512180 0 512180 0% /dev/shm

Déterminer l'espace disponible du TMP ( il faut environ 150Mo à 200Mo)
[oracle@dsiege103829 oracle]$ df -m /tmp
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/VGsys-tmpLV
992 36 906 4% /tmp


Vérifier les packages d'installer

rpm -qa | grep package_name

Liste des packages nécessaires
compat-libstdc++-33.2.3-47.3
elfutils-libelf-0.97-5
elfutils-libelf-devel-0.97-5
glibc-2.3.9.4-2.19
glibc-common-2.3.9.4-2.19
glibc-devel-2.3.9.4-2.19
gcc-3.4.5-2
gcc-c++-3.4.5-2
libaio-devel-0.3.105-2
libaio-0.3.105-2
libgcc-3.4.5
libstdc++-3.4.5-2
libstdc++-devel-3.4.5-2
make-3.80-5
sysstat-5.0.5
unixODBC-2.2.11
unixODBC-devel-2.2.11

How to display the top three earners in the employees table.

SELECT last_name, salary FROM employees e WHERE 3 > (SELECT COUNT (*) FROM employees WHERE e.salary

Why and when should I backup my database?

Backup and recovery is one of the most important aspects of a DBA's job. If you lose your company's data, you could very well lose your job. Hardware and software can always be replaced, but your data may be irreplaceable!

Normally one would schedule a hierarchy of daily, weekly and monthly backups, however consult with your users before deciding on a backup schedule. Backup frequency normally depends on the following factors:

• Rate of data change/ transaction rate
• Database availability/ Can you shutdown for cold backups?
• Criticality of the data/ Value of the data to the company
• Read-only tablespace needs backing up just once right after you make it read-only
• If you are running in archivelog mode you can backup parts of a database over an extended cycle of days
• If archive logging is enabled one needs to backup archived log files timeously to prevent database freezes
• Carefully plan backup retention periods. Ensure enough backup media (tapes) are available and that old backups are expired in-time to make media available for new backups. Off-site vaulting is also highly recommended.

Frequently test your ability to recover and document all possible scenarios. Remember, it's the little things that will get you. Most failed recoveries are a result of organizational errors and miscommunication.

Liste des plus grandes consommations CPU

Ce script SQL permet d'afficher les opérations les plus gourmandes en terme de CPU
 
SET echo off
SET feedback off
SET linesize 512 

1. prompt ----------------------------------
2. prompt - plus grandes consommation CPU --
3. prompt ----------------------------------
4.  
5. COLUMN sid format 999 heading "SID"
6. COLUMN username format a20 heading "Utilisateur"
7. COLUMN command format a20 heading "Commande"
8. COLUMN osuser format a20 heading "Utilisateur OS"
9. COLUMN process format a20 heading "Processus OS"
10. COLUMN machine format a20 heading "Machine"
11. COLUMN value format 99,999 heading "Temps CPU"
12.  
13. SELECT
14. s.sid sid,
15. s.username username,
16. UPPER(DECODE(command,
17. 1,'Create Table',2,'Insert',3,'Select',
18. 4,'Create Cluster',5,'Alter Cluster',6,'Update',
19. 7,'Delete', 8,'Drop Cluster', 9,'Create Index',
20. 10,'Drop Index', 11,'Alter Index', 12,'Drop Table',
21. 13,'Create Sequencfe', 14,'Alter Sequence', 15,'Alter Table',
22. 16,'Drop Sequence', 17,'Grant', 18,'Revoke',
23. 19,'Create Synonym', 20,'Drop Synonym', 21,'Create View',
24. 22,'Drop View', 23,'Validate Index', 24,'Create Procedure',
25. 25,'Alter Procedure', 26,'Lock Table', 27,'No Operation',
26. 28,'Rename', 29,'Comment', 30,'Audit',
27. 31,'NoAudit', 32,'Create Database Link', 33,'Drop Database Link',
28. 34,'Create Database', 35,'Alter Database', 36,'Create Rollback Segment',
29. 37,'Alter Rollback Segment', 38,'Drop Rollback Segment', 39,'Create Tablespace',
30. 40,'Alter Tablespace', 41,'Drop Tablespace', 42,'Alter Sessions',
31. 43,'Alter User', 44,'Commit', 45,'Rollback',
32. 46,'Savepoint', 47,'PL/SQL Execute', 48,'Set Transaction',
33. 49,'Alter System Switch Log', 50,'Explain Plan', 51,'Create User',
34. 52,'Create Role', 53,'Drop User', 54,'Drop Role',
35. 55,'Set Role', 56,'Create Schema', 57,'Create Control File',
36. 58,'Alter Tracing', 59,'Create Trigger', 60,'Alter Trigger',
37. 61,'Drop Trigger', 62,'Analyze Table', 63,'Analyze Index',
38. 64,'Analyze Cluster', 65,'Create Profile', 66,'Drop Profile',
39. 67,'Alter Profile', 68,'Drop Procedure', 69,'Drop Procedure',
40. 70,'Alter Resource Cost', 71,'Create Snapshot Log', 72,'Alter Snapshot Log',
41. 73,'Drop Snapshot Log', 74,'Create Snapshot', 75,'Alter Snapshot',
42. 76,'Drop Snapshot', 79,'Alter Role', 85,'Truncate Table',
43. 86,'Truncate Cluster', 88,'Alter View', 91,'Create Function',
44. 92,'Alter Function', 93,'Drop Function', 94,'Create Package',
45. 95,'Alter Package', 96,'Drop Package', 97,'Create Package Body',
46. 98,'Alter Package Body', 99,'Drop Package Body')) command,
47. s.osuser osuser,
48. s.machine machine,
49. s.process process,
50. t.value value
51. FROM
52. v$session s,
53. v$sesstat t,
54. v$statname n
55. WHERE
56. s.sid = t.sid
57. AND
58. t.statistic# = n.statistic#
59. AND
60. n.name = 'CPU used by this session'
61. AND
62. t.value > 0
63. AND
64. audsid > 0
65. ORDER BY
66. t.value DESC;