I’ve been patiently awaiting some news on exactly how Apple planned to fulfill the battery claims on iPods and finally there is news… Unfortunately it is not good.

On October, 24 Apple filed an appeal to the settlement on a class action suit which would have forced Apple to replace or repair iPods which failed to meet their originally claimed battery life. While I understand this is big business and big money I am very disappointed with this move by apple.

The settlement, which may still go through, was expected to cost Apple a mere $15 million. I wonder how much Apple will spend on the appeal, and meanwhile I have a third generation iPod which is just over two years old which will not last an hour on battery.

According to the official settlement administration website the appeal could take “up to a year or more”. I was really hoping Apple would replace or repair my iPod before it became obsolete.

I would like to think Apple would learn a lesson from this, but with the iPod Nano, Shuffle, and new Video iPods having the same closed-box construction which all but demands you send the unit back to Apple for a battery replacement I’m afraid they just won’t learn.

So a 60 gig iPod goes on the Christmas list, but until Apple comes through with a slightly more user serviceable model I’ll always be just a little shy of the iPod. Apple should be able to do better.

apple,ipod,battery,ipod settlement, ipod nano, ipod shuffle, ipod battery, macintosh

v$views


The Warning Label Generator allows you to choose from a variety of labels and symbols and free-form your text in to create your own warning labels. Lots of fun! Thanks to the Make Magazine blog for pointing this one out!

warning label, label, fun, entertainment, humor, funny

Don’t just grow your TEMP tablespace, examine it!

Recently I was facing a problem not unusual in high-throughput Oracle databases… a full TEMP tablespace. I’ve run into this before and it can be frustrating trying to determine where all the space went. In this case we are using a 6 gig temporary tablespace and for some reason it was full.

Well, all the gorey details aside, one thing that helped me determine what was going on was this tip from Oracle which contains code to examine who is using your temporary tablespace up.

By running the following command (reprinted here for easy reference and because there are nasty line breaks on Oracle’s site) you get a fairly good idea of the usage of temporary space by tablespace, username and amount used.

set pagesize 10000
set linesize 133
column tablespace format a15 heading 'Tablespace Name'
column segfile# format 9,999 heading 'File|ID'
column spid format 9,999 heading 'Unix|ID'
column segblk# format 999,999,999 heading 'Block|ID'
column size_mb format 999,999,990.00 heading "Mbytes|Used"
column username format a15
column program format a15

select b.tablespace, b.segfile#, b.segblk#,
round(((b.blocks*p.value)/1024/1024),2) size_mb,
a.sid, a.serial#, a.username, a.osuser, a.program, a.status
from v$session a, v$sort_usage b, v$process c, v$parameter p
where p.name='db_block_size' and a.saddr = b.session_addr
and a.paddr=c.addr
order by b.tablespace,b.segfile#,b.segblk#,b.blocks;

While I consider rewriting this into a somewhat more palatable form, on the occasion that I need this I don’t typically care about nice formatting… I just want the numbers in a hurry.

To clear up unused TEMP space Oracle also recommends running this as sysdba:

alter tablespace temp default storage(pctincrease 0);

oracle, dba, database, database administration, database administrator, database tuning

What are the valid characters for Oracle passwords? This is a more complicated question than you would think. Here are the basic restrictions on Oracle passwords. I believe these apply to all (8i or later) Oracle database versions; however I did these examples in a 10gR2 instance.

First the rules:

Passwords can be from 1 to 30 characters.

The first character in an Oracle password must be a letter.

Only letters, numbers, and the symbols “#”, “_” and “$” are acceptable in a password.

Examples:

SQL> alter user jemmons identified by abc123;

User altered.

SQL> alter user jemmons identified by 123abc;
alter user jemmons identified by 123abc
*
ERROR at line 1:
ORA-00988: missing or invalid password(s)

SQL> alter user jemmons identified by abc!123;
alter user jemmons identified by abc!123
*
ERROR at line 1:
ORA-00922: missing or invalid option

In the first example we see a password that meets all the rules. The second password starts with a number and therefore fails. The third example contains the special character “!” and fails.

Now the exception:

By placing double quotes around a password you can use most standard ASCII characters in a password.

Examples:

SQL> alter user jemmons identified by "123abc";

User altered.

SQL> connect jemmons/123abc;
Connected.
SQL> alter user jemmons identified by "abc!123";

User altered.

SQL> connect jemmons/abc!123;
Connected.

We see that the quotes let us work around some of these restrictions. This is useful if you are working in a fairly simple environment, however if it is possible that a user’s password could be changed by means which you do not control it is likely doing this would cause more confusion than it would solve.

It is also worth note that capitalization is not considered when storing Oracle passwords. Here’s an example:

SQL> alter user jemmons identified by ABC123;

User altered.

SQL> connect jemmons/abc123;
Connected.

Before the password is encrypted into the database it is put in all caps. When you enter a password for authentication it is capitalized so it can be compared against the stored encrypted password.

oracle, dba, database, database administration, database security, database administrator

With Oracle 10g there has been a small but useful change made to Oracle’s Optimal Flexible Architecture.

The Optimal Flexible Architecture standards are a guideline for setting up Oracle databases to minimize downtime and maximize scalability. For more information, check out my article on OFA.

In 10g, Oracle has added one level to the ORACLE_HOME path. An Oracle home directory which was formerly /u01/app/oracle/product/9.2.0 is now one more level deeper at /u01/app/oracle/product/10g/db_1.

By adding install type and an install number as the final level of the Oracle home variable it is now possible to have two or more installs of the same version of Oracle in the same Oracle directory.

Oracle offers up the idea of using db_1, db_2 and so-on for full database releases and client_1, client_2 and so-on for client installs I can also see using this method to install Oracle applications servers in the same directory as well.

To read more about OFA, check out my earlier article on the topic and Oracle’s explanation of OFA.

oracle, sql, dba, database administration, database development, database security, database, oracle security

« Previous PageNext Page »