Heh! When I were younger, in the early '90s, our uni had a Pyramid with 2 whole CPUs running AT&T Unix! Programming students could bring it to its knees with their buggy chat client projects. Unix, or something very much like it, is now not only potentially free, but infinitely more stable. And now Oracle gives you high availability services that will auto restart things, or you're running on a RAC cluster, and when an instance crashes the end user simply experiences a bit of a pause, if that. There's nothing like being able to patch the database software across all 3 nodes in a cluster (1 instance down at any one time) while the users are logged in and actively using the application it back-ends.
Four Yorkshire-men aside, sometimes you need those 3 instances as 1 crashes because you're using the new feature and another inexplicably refuses do any work because of some buggy load balancing algorithm. (ok, perhaps some exaggeration here, but not by much)
Dude, I reckon you're behind the times. There have been 4 major releases since 10g - 10gR2, 11gR1, 11gR2 and now 12c. Even if you take R1/R2 as one major release, that's still 2 major versions. 10g is what, 8 years old and afaik unsupported by oracle except maybe in extended fashion on the latest patch level. What were the limits back in '05 on "current" Postgres?
Invalidation of interdependent objects will show you ultimately which part of your application is broken when you compile a new package or change some DDL, and thus when it's safest to do the more invasive stuff - unless of course you've used object editioning as it's supposed to be used (as of 11gR2) so both old and new code can coexist on your database, and you can switch users over to the new code, piecemeal or wholesale without interruption or pesky invalidations if you know what you're doing.
There are still gotchas though, like the magical GoldenGate, which can give you an architecture independent replica of your database (for a price of course) oh except for the handful of special tables you want to copy but it doesn't support yet.;)
I suggest playing with XE to see what the free version can do for you now. And read up on 12c features. It may only be a matter of time before Postgres can do the ones you want, and Postgres may even do it better when it does the implementation (I've no doubt Oracle's database code resembles spaghetti even now). Postgres exists for a reason, and I only wish it were better recognised than MySQL as a real long time ACID compliant RDBMS.
Yep, I've joined the dark side, but perhaps I can still be turned back...
From experience, TOAD isn't great for managing RAC stuff (I use TOAD, but not for that!) I'd use the database management interface that comes with the database installation, or take a step up from that and use Oracle's OMS, especially given that its license is now essentially free if you avoid trying to use certain largely irrelevant frills like cloud management. OMS will help you do your impdp and if you know how, compare / make changes to multiple databases simultaneously if you dare. You can even download and install a limited license Oracle database for free - http://www.oracle.com/technetwork/products/express-edition/overview/index.html - it comes with a browser based GUI and all, if resource limited - but comes in setup.exe and RPM form.
Manual management of tablespaces??? Create your datafiles for your tablespaces on an ASM diskgroup, set them to autoextend, set up an email alert for when the tablespace gets to 90% full or whatever suits so you can add more files if you underprovisioned, and set up another alert to tell you when your ASM diskgroup is getting full. Manual management is very much dark ages stuff (although some currently supported software insists that is how you configure things... or asserts its configuration on you which then you have to bend to your will... grrrr).
Datafile size limitations - default sizes these days with default block / ASM extent sizes amount to 32G per datafile in 11g. If you know the data will be huge, increase the extent sizes. Doubling one will double the other, and so on... or create a HUGEFILE tablespace, which is 1 essentially unlimited size file.
Recompiling invalid objects? From the database server, login as SYSDBA and: @?/rdbms/admin/utlrp... done! Incidentally, utlirp followed by utlrp allows you to upgrade your database objects from say 32 bit to 64 bit. Oracle's upgrade methodology for the most part allows you to choose one of a few methods depending on source and target platform, and if you follow the documented procedure it will usually just work.
Oracle databases are more complex because the software can do more for you. If you don't need the complexity, install Postgres - I'd choose Postgres in a heartbeat if all I needed was a solid RDBMS with a useful interface. And I'm sure you can still do funky things with Postgres anyway if you want to practice black magic! Horses for courses though. If it doesn't make sense to use Oracle, and you're not forced to use it, then don't!
The UI is much prettier these days, and improving with each release... thankfully! Never had to do any installations up to version 8, but 9i was _bleep_, 10g was pretty crap... 10gR2 bearable. 11g was a step in the right direction and 11gR2 not too shabby. Haven't had the time to install 12c yet myself, but the installers for their other (predominantly weblogic) work pretty well when you can get your head around the installation guides, assuming you're doing something non-vanilla. IMNSHO of course.
Oh yeah there was the time I uninstalled a piece of application software with the OUI, and as well as what was expected it deleted 1 library out of another oracle installation. Finding that was LOADS of fun. But that was in the 10g days. If you go with 12c, when they release an upgrade you're supposed to install the new software, unplug your database from the old home and plug it into the new one (aka pluggable databases). I'd wear a little pain with the installer for that feature.
Also not for the faint of heart, the grid infrastructure software which provides the cluster / ASM support weighs in around the ballpark of 1G of RAM usage, before starting up your RDBMS. Not much of an issue when the cost of RAM is such that the average home enthusiast can afford 16G or more of the stuff. But when you use the features (because you need them), it's approximately worth it.
> Flashback queries and flashback archives (they are really cool) Is that the same as time travel?
Nope, in Oracle you can run this query on any table to view the data it held yesterday:
select * from emp as of timestamp(sysdate-1);
Better still:/* Which employee records did Joe accidentally drop again? */ select * from emp as of timestamp(sysdate-1) where empid not in (select empid from emp/* as of right now */);... to see what you've dropped, and say if you know it was only that table affected then you don't even have to shutdown the database to get it back: insert into emp (---insert above query here---);
At database level it's common before a potentially risky data change to create a flashback point, and if it messes up, shutdown, revert to the time you created the flashback, and pretend the changes never happened. It happens as fast as all the necessary extents can be written back to the data files and the database can be restarted.
But but but... you are paying for those features. ~$10k per pair of intel cores per year before haggling... if all you want is a rock solid database, Postgres should be at least as good, and at a much lower price.
I've been a relatively mild-mannered open source advocate for over 20 years now, and have been running Linux for all of it. My first DBA job was with Postgres (6 or 7, ~12 years ago now!) and now Oracle. This is all about databases, completely ignoring the application related acquisitions they've made in the last decade...
A lot of difference I see and is evident from the discussions here is that Oracle usually has the features earlier (not always, but yes, usually). The earliest example I've witnessed is Postgres' Write-Ahead Logging, which was definitely cool, but Oracle were there first. More recently, with 11gR2 you have advanced compression (pay $$$$ and it will store all your data compressed if you want) and with 12c there are a bunch of features that make me drool. Pluggable databases is just one of them.
Again, not entirely sure about Postgres, but Oracle build a lot of instrumentation into the database software itself. Tracing custom events is a great way of profiling your application as well as database deficiencies. Pay for the license to unlock the full power of ASH or AWR and you have a great deal of ability to see exactly what's going on and figure out how best to resolve any performance issues. The best bit is that this instrumentation doesn't make the database run like a dog. A few percent overhead gives you a lot of debugging power, and it's ALWAYS turned on with basic event tracking always happening anyway. But you can add MOAR.
I see some impressive performance on Oracle databases these days, but not entirely convinced that Postgres cannot meet them. But then, Oracle can run on anything from 32 bit x86 to some seriously beefy hardware (and when it does, it runs well). I'm not entirely sure about Postgres, but I know Oracle has been compiled for RISC architecture (Power, SPARC, HPUX, others??) for a long time. These days they to lean towards x86 - and will even sell you a "database machine" (google for Exadata). This extends to scaling out on any of the supported architectures with their cluster software (Grid Infrastructure) these days, which is quite mature now. Again, Postgres probably does this, but each generation sees a significant improvement for Oracle.
Having said all that, leading edge can also be bleeding edge... The biggest problem for me with Oracle continues to be the time it takes to resolve software bugs combined with their support infrastructure. While it usually gets there in the end, for the price you pay for enterprise support one might expect quicker resolution if you happen to be the first person to hit upon a specific problem. Unfortunately this tends to tie with the need to certify with all the Oracle applications they release and support. The one and only bug I reported when I was a Postgres DBA was around a date calculation issue - from the behaviour I reported it was tracked down and patched in ~ 2 days, and I had a workaround for the meantime anyway.
Oracle have also done some cool stuff in the open source domain with OCFS (and now OCFS2) and the free domain with their base GI cluster software, as well as the plain cool domain with ASM (dynamically manageable disk pooling with Stripe And Mirror Everything methodology providing solid data robustness) and ACFS which lets you carve out clustered POSIX compliant filesystems on top of ASM at will. This all helps with scaling (don't need OCFS2 now if you use ACFS tho).
Hmmm, it seems they really are turning me to the dark side.... heeellllllppppp!!!!
Firstly, no I don't work for Oracle, and never have, and I know how hard it can be to justify using their products, especially the ones you pay for(!) considering some of the things I've seen, but credit where credit's due...
OCFS was originally designed specifically for storing Oracle datafiles, in a cluster, in a non-POSIX fashion. After that came OCFS2, which is POSIX compliant, but can deadlock when NFS exported due to the way NFS handles locking, in a way that can be worked around with the "nodirplus" NFS mount option (not available on all OSes, but Linux is ok). They since developed ASM (Automatic(ed?) Storage Management) which threw away the traditional filesystem presentation of your oracle datafiles, and subequently bundled that into the release of 11gR2 clusterware and extended the functionality to give us ACFS - ASM Clustered Filesystem.
11gR2 clusterware is designed to be clustered with shared storage, and depending on the options when created will happily give you a POSIX compliant clustered filesystem for any occasion - datafiles, regular files - whatever. It is Oracle's implementation of their "best practice" Stripe And Mirror Everything methodology with the aim of not only high availability, but consistently high performance, through spreading all your data across all your disks, and implementing mirroring in a sane way too (split your disks into two (or three!) failure groups, and the software will ensure there are 2 (or 3!) copies of each block. All you do is add disks to the pool(s), and if you have the space you can dynamically remove disks from the pool too. You can fsck, mkfs, mount and unmount it, take snapshots (!), and the lead-up to all that is all not much of a stretch from LVM. Google for Oracle ACFS and see the "Basic Steps to Manage Oracle ACFS Systems" section.
OCFS was only ever available for Linux, but ACFS now supports other platforms... probably doesn't matter to you. The one catch I've found so far is the ~1Gb RAM overhead to run the clusterware PER NODE. There's other reasonable stuff, like you need the network layer to be up in order to start the ACFS supporting services, so you can't put anything related to the basic boot process on those volumes.
The cost of 11gR2 clusterware?... nothing. I think it's one of very few "free" (as in beer) products they do. It will work on anything they've compiled it for though - generally means your Enterprise OS like RHEL5 (and should be easy to shoehorn onto CentOS), a recent SuSE release, and of course their own Oracle Enterprise Linux - which I believe is also free to use, but pay through the nose if you want them to support your implementation. Remember that this system is the platform for some very expensive Oracle products, but at the same time it is perhaps a younger product than some you'll have already looked at.
As for the fencing method, it all works via heartbeat to disks in your ACFS pool. If the clusterware can't "ping" the disk within the threshold, it forces the system that's having the issue to reboot. Such is the nature of ensuring sanity when using shared disk. I suggest looking at it if your boxen can spare the RAM and you're happy to accept their OTN license agreement, as it really does seem to be one of Oracle's better products at an amazing price for what you get.
Preface: I play with RedHat at work, and CentOS at home...
All fine, except if the system isn't for Oracle products then the vendor supporting the app will look at you funny when you tell them what enterprise OS you're running on.
RHEL has a certification relationship with many vendors. OVM, CentOS, and even to some degree Fedora, while being very similar as far as the administrator is concerned, are completely different when it comes to what level of supportability you'll get. At least 2 of those won't be particularly interested.
Of course, if you're supporting your own custom application then the answer is to run whatever OS you're comfortable with. If you want RedHat to look as a matter of priority at a technical problem you're having that is say related to their kernel, you'll have to pay them the license fee for that level of support. If your CIO wants a vendor to take some accountability, it has to cost something...
Then there are the certain applications that check the contents of your/etc/redhat-release file, and if they aren't happy with the answer, they'll refuse to go on. Of course, that's only a text file that any superuser can create.:)
So... ummm, can you tell me what the wind speeds were for the handful of hours prior to the reported elevated levels, or even how long the elevated level was recorded for in Tokyo? I'm only particularly interested in facts to prove me wrong, not speculation.:)
Nobody really bothers with reporting good news (great news, yes, good news doesn't sell). Bad news of any kind loves to spin. If the radiation levels vary significantly over even the next week (this must include going down) then there are no dangerous radioactive materials involved - such things have significantly higher half lives than seconds, minutes, or hours... even days.
Despite the explosions, this "disaster" is still officially at least 1 level lower than TMI ever was, and that was more bark than bite. No meltdown. Some heavy-ish elements in the reactor may be somewhat dangerous to get close to for a while, and if they escape they will be of mild concern because they can't sustain a reaction like you get in a nuclear reactor, whether it be for power (Uranium/Plutonium and other scary stuff) or medicine (not so scary, but still troublesome to carry lumps in your pocket). The half-life of those materials within the reactor will be what determines the time it takes from the control rods being inserted to the reactor going cold (and yes there will be significant residual radiation inside the reactor in normal circumstances). Current temperatures within the reactor simply won't be high enough to vaporize much that could be a threat. It's just better for you not to inhale the stuff that is out there, just as it's better for you not to inhale cigarette smoke.
Math fail... firstly, pounds??? The units we're interested in are milli/microsieverts. Who's talking pounds? Look up the unit, you'll find Wikipedia has useful information on what constitutes a danger... look it up and repeat after me: Oh, it's not all that bad.
Secondly, think beyond the narrow-minded figure that "minutes" means no more than 10 minutes...
Say the half life of the radioactive gasses escaping the power station is 30 minutes. yes, 30. It's not unthinkable. In that case 400 millisieverts (reported to be an exposure at the reactor) becomes 25 millisieverts after 2 hours, or ~1.5 millisieverts after 4 hours, or somewhere in the region of reported levels in Tokyo after 5 hours or so. Is a 50km/h sea breeze enough for you in a tropical region? This means the radioactive material in the atmosphere is decaying fast enough not to pose a significant health issue. If there is enough exposure to worry about, people start taking iodine pills. Sure, iodine pills have even been distributed around the area, but how many have actually been taken so far? Possibly that one exposed worker, and whoever decided to panic.
Yes, we're still quite peachy. Conventional fuel based explosions have happened at a nuclear power plant, because a byproduct of the residual reaction is an ideal, carbon-free, fuel (H2), and it ignited. When the reactor shutdowns, which have been hampered by the problems at the plant, complete, then the properly protected experts can have a look and the full story on how much dangerous nuclear matter has been released into the atmosphere will come out. I think you'll find it's negligible. The Japanese should be worrying about other things than the potential for a nuclear holocaust.
*sigh*... half life of minutes means it halves radiation level measured every so many minutes, doesn't mean it disappears in minutes. Revise your math based on that.
Generally the most dangerous nuclear material is that with a half life comparable to the lifespan of a human, ie decades. Yes there are spikes of radiation, but they dissipate quickly. 23 times the normal levels? I receive a day's worth of background radiation in an hour... as long as that doesn't happen for a month it's not likely to affect my health.
The real problem is if the nuclear fuel escapes into the atmosphere - that's where you end up with clouds that are dangerous. It hasn't happened in Japan yet, despite the physical assault the earth has thrown at it. Radioactive gases have been vented, and are short lived, and low risk because it's total exposure to radiation that causes the real health issues.
So far I still only see reports of one worker exposed to levels of radiation that are equivalent to a few years worth of radiation in an hour. That person may get cancer, and has every right to be worried, but you can get cancer from inhaling coal dust too. Or smoking, or, depending on what the media wants to pick up and run with, eating potatoes, or breathing. The point is, don't believe the hype that the media is using to sell stories. They don't seem to know what they're talking about. As soon as someone admits "radiation leak" the media broadcasts "Chernobyl" and the average Joe starts overreacting. These stories are alarmist, pure and simple, and it's selling newspapers and online advertising, while at the same time putting enough fear into people to affect the rescue and recovery efforts from the natural disaster.
I were in Tokyo I'd keep an eye out for any official reports about a genuine containment failure, while continuing to live my life.
Oh yes, those who use this as a tool to fear nuclear power need also to remember that this is a 40 year old plant, and there is new technology in such things which prevents the chance of even a partial meltdown, period. Very clever stuff where the fuel is embedded in material that expands as it gets too hot, which effectively moderates the fission reaction and prevents it going past a certain point.
I think we'll find the risks associated with earthquakes and tsunamis at say a gas or coal powered power station would be about the same. This tangent seems to have completely forgotten the magnitude of mother nature's fury which caused the issues in the first place.
Thousands were dead in minutes, and people seem to be insinuating that a fatality and some injuries after the natural disasters are beyond what might be considered statistically normal. Accidents happen, however unfortunate they may be.
Bollocks. While the outcome was not ideal, the evacuations were just precautionary.
The reason for the explosions is due to the knowledge that the hydrogen/oxygen gas mix released would be marginally radioactive with a half life measured in seconds, and the intent was to contain the gas for long enough for it to be rendered inert. The risk of explosion was acknowledged, people were warned, and when when it did blow, well they had had opportunity to move people further away than they were. The escaping gases ARE raising radiation levels... a bit. However, I think you'll find the radiation doses astronauts get are higher than those the bunnies outside the fences of the nuclear power plants are getting.
It takes a few days for a reactor that has had the control rods slammed into the shutdown position to cool down, and in the meantime the generator still generates some heat and needs some cooling. When the backups and backups of backups failed, they chose the less desirable route, in pumping in sea water. As it ain't pure water, you end up with slightly more radioactive matter with a half-life which is more like minutes than seconds, so less desirable, somewhat radioactive gas results, which is harmless well before it travels that 30km. There will be no noteworthy radioactive residue when the cool down is complete, except for what's in the reactor itself.
The reactor everyone's jumping up and down about has survived an earthquake and tsunami well beyond design spec, and as for the inconvenience of lost power. Yes, they lost backup and backup backup diesel generators, but they also had battery backups which held until mobile generators could be moved in. I also dare anyone to tell me what power generation scheme in that location at that time would not have failed, so of course there will be power rationing and/or blackouts.
The Japanese got the sum of their design and processes of their nuclear reactors right, and they are taking every precaution they can to ensure public safety. The biggest mistake was trying to contain the gas from the reactor instead of venting to the atmosphere, because the media are making it look like these gas explosions might be a sign that a meltdown is imminent. It isn't, but the media never let facts get in the way of a good story. Those responsible for the reactors are simply Doing The Right Thing [TM].
Based on what Mr Atkinson has alleged in the past, it's far more likely that what actually happened was a gamer slipped him an e-mail that said something along the lines of "I'm 19 now and you have to let me see b00bs in a game if I want! Otherwise if you ever show up in <Online FPS>, me and my buddies are going to camp all the spawn points and frag you 'til you cry to your mum!"
2) If there's ever any problem with memory, create a swap file (if you don't have one yet) and type swapon on a live system.
1) is not the best idea, at least for Linux. One of the things the Linux kernel can effectively use swap for is defragmenting memory! Swap a chunk of memory out to disk, and read it back in at a more suitable location. A long-running, hard working kernel will reward you even for a measly 256M swap partition - eventually.
2) Swap files are significantly slower than swap devices. Consider this: Your swap file lives on a filesystem. Your system decides it's struggling with memory and begins trying to swap some cached files out (it may assume that swapping them out and back in again is faster than re-reading off the original disk)... potentially onto the same disk the originals come from, causing more thrashing. It may even have to consider whether it can to swap out bits of the swap file! Plus you're dealing with filesystem layers which will only slow down the process... so give it at least one device/partition as a priority, and add swap files with a lower priority for temporary/emergency purposes only, if you care about performance.
The amount of swap any system requires is very situation/application dependent. If your system isn't using swap much at all, then good for you! Don't throw a lot of swap at it! But be nice to your Linux kernel, and give it something to use for its own sanity.
Oh i probably would, given the choice...:) My problems are caused by these things:
I only assemble 1 PC every year or so...
Approximately half are for other people,
I insist that the I'd be happy with the box under the circumstances they're in,
They're on a budget, so I prefer to spend the little extra they can afford on an Asus mainboard instead of the case.
I also don't charge for the time or effort, as long as they're willing to wait for me to have the time to take them shopping for parts and make a mess in their living room.
I don't mind taking the risk, as it's not like losing a few ccs of blood every year or so will be a problem. It's just fun to note how vicious those $!@^#!s can be. It doesn't have to be a big slip to get yourself sliced open, and I swear the cases resent the fact that they're going to have to get along with the new motherboard so they go out of their way to ensure the slip is big enough!
What the heck, typical box I would have assembled for a friend last year:
~Intel P4 3GHz (these days I would as likely choose AMD)
ASUS mainboard - usually Deluxe but without onboard graphics, 1Gb network card. Onboard sound is fine (5.1 is more than these friends are likely to use:)
The current $100-200 graphics card, 128Mb - NVidia or ATI depending on who's just dropped their prices.
Minimum 80Gb hard drive.
One extra case fan - preferably not Neon
2x512Mb RAM to suit the mainboard. Would have been DDR2 I guess.
A Liteon or other standard DVD burner, probably 8x.
Microsoft Keyboard/Mouse OEM package. NOT wireless. Batteries, bleah!
Standard Sony floppy drive
Surge protector or UPS according to budget and value of their data
Monitor according to budget - reasonable response LCD or larger CRT.
$30 speakers. If they want immersion then they can use headphones:p
I would have also ensured they got an OEM copy of XP Home, and set up Firefox/Thunderbird/AVG at the very least.
I wouldn't say they're experienced gamers at all, but have had no complaints apart from a couple of dodgy power supplies - one the shop was happy to replace, the other was just mine and a little out of warranty.:p
Doesn't need to be running... every single time I've done assembly or reassembly involving a new motherboard, the case has drawn blood. A little matter of needing to use a little force to get something to snap into place... and it gives more suddenly than expected. About half the time has required a band-aid to prevent getting blood everywhere. I guess that's the main downside of many cheaper cases - sharper edges!
Craft like the stealth bomber work by scattering radar signals so they return almost any which way but back to the sender, making them appear a lot smaller than they really are. If there were something in the shadow of its profile, you wouldn't see that either. You would get no significant "ping" from your radar signal.
This theory, if it works and proves practical, would change things so you would get no reflection off the bomber, but you would see the object behind it just the same as if the craft wasn't there. There would be a radar blip! The downside for the bomber is if the object behind was a legitimate target, the bomber would be hit by shots aimed at the object behind.
It sounds like any effective cloak created using this any time in the "near" future would only really be effective for static installations.
IMHO true computer literacy is knowing your current limitations, and knowing that you can't pretend they don't exist. Add the knowledge of how to research what you need or teach yourself and the world should be your oyster. Many moons ago I got a job after an interview which included a question like "Do you know HTML?" The answer was of course, yes. Then I went home, found suitable references, read the book, and practiced it. By the time I started working for them I knew more about the standard then than I do now.
That's when you should be able to sit through an interview and easily convince a potential employer that even if you don't know the semantics of language X, you'll know the basics in 24 hours and by the time you start work the following Monday you're basically fluent in it. Better still, when you apply for the job, learn at least the basics of the language before the interview. Just remember that a) your style of approach to a solution is often just as important as your general knowledge of the technology and b) all bullshit will get you in a smart workplace is unemployed again 2 weeks later.
I had a theory about this some time ago... it basically boiled down to classifying objects by:
Whether the object is orbiting something else
The size of the object
The amount of work required to escape the object's gravity well - whether to escape altogether, or get into the partner object's gravity well.
Of course, the easiest way to set boundaries for these involves some kind of galactic pogo stick to determine whether you can jump from one object to the next.:)
Slashdot Mirror
Don't they mean watching their acting lessons? I'm wondering which team gets the best chance at an academy award this year.
... more of a commentary around the importance some people place on social media. Slightly tabloid, this slashdot article is. Mmmm...
Heh! When I were younger, in the early '90s, our uni had a Pyramid with 2 whole CPUs running AT&T Unix! Programming students could bring it to its knees with their buggy chat client projects. Unix, or something very much like it, is now not only potentially free, but infinitely more stable. And now Oracle gives you high availability services that will auto restart things, or you're running on a RAC cluster, and when an instance crashes the end user simply experiences a bit of a pause, if that. There's nothing like being able to patch the database software across all 3 nodes in a cluster (1 instance down at any one time) while the users are logged in and actively using the application it back-ends.
Four Yorkshire-men aside, sometimes you need those 3 instances as 1 crashes because you're using the new feature and another inexplicably refuses do any work because of some buggy load balancing algorithm. (ok, perhaps some exaggeration here, but not by much)
Dude, I reckon you're behind the times. There have been 4 major releases since 10g - 10gR2, 11gR1, 11gR2 and now 12c. Even if you take R1/R2 as one major release, that's still 2 major versions. 10g is what, 8 years old and afaik unsupported by oracle except maybe in extended fashion on the latest patch level. What were the limits back in '05 on "current" Postgres?
Invalidation of interdependent objects will show you ultimately which part of your application is broken when you compile a new package or change some DDL, and thus when it's safest to do the more invasive stuff - unless of course you've used object editioning as it's supposed to be used (as of 11gR2) so both old and new code can coexist on your database, and you can switch users over to the new code, piecemeal or wholesale without interruption or pesky invalidations if you know what you're doing.
There are still gotchas though, like the magical GoldenGate, which can give you an architecture independent replica of your database (for a price of course) oh except for the handful of special tables you want to copy but it doesn't support yet. ;)
I suggest playing with XE to see what the free version can do for you now. And read up on 12c features. It may only be a matter of time before Postgres can do the ones you want, and Postgres may even do it better when it does the implementation (I've no doubt Oracle's database code resembles spaghetti even now). Postgres exists for a reason, and I only wish it were better recognised than MySQL as a real long time ACID compliant RDBMS.
Yep, I've joined the dark side, but perhaps I can still be turned back...
Amen! At least they don't license based on available RAM yet. Oh darn, I hope Larry doesn't read this and get any ideas. ;)
From experience, TOAD isn't great for managing RAC stuff (I use TOAD, but not for that!) I'd use the database management interface that comes with the database installation, or take a step up from that and use Oracle's OMS, especially given that its license is now essentially free if you avoid trying to use certain largely irrelevant frills like cloud management. OMS will help you do your impdp and if you know how, compare / make changes to multiple databases simultaneously if you dare. You can even download and install a limited license Oracle database for free - http://www.oracle.com/technetwork/products/express-edition/overview/index.html - it comes with a browser based GUI and all, if resource limited - but comes in setup.exe and RPM form.
Manual management of tablespaces??? Create your datafiles for your tablespaces on an ASM diskgroup, set them to autoextend, set up an email alert for when the tablespace gets to 90% full or whatever suits so you can add more files if you underprovisioned, and set up another alert to tell you when your ASM diskgroup is getting full. Manual management is very much dark ages stuff (although some currently supported software insists that is how you configure things... or asserts its configuration on you which then you have to bend to your will... grrrr).
Datafile size limitations - default sizes these days with default block / ASM extent sizes amount to 32G per datafile in 11g. If you know the data will be huge, increase the extent sizes. Doubling one will double the other, and so on... or create a HUGEFILE tablespace, which is 1 essentially unlimited size file.
Recompiling invalid objects? From the database server, login as SYSDBA and: @?/rdbms/admin/utlrp ... done! Incidentally, utlirp followed by utlrp allows you to upgrade your database objects from say 32 bit to 64 bit. Oracle's upgrade methodology for the most part allows you to choose one of a few methods depending on source and target platform, and if you follow the documented procedure it will usually just work.
Oracle databases are more complex because the software can do more for you. If you don't need the complexity, install Postgres - I'd choose Postgres in a heartbeat if all I needed was a solid RDBMS with a useful interface. And I'm sure you can still do funky things with Postgres anyway if you want to practice black magic! Horses for courses though. If it doesn't make sense to use Oracle, and you're not forced to use it, then don't!
The UI is much prettier these days, and improving with each release... thankfully! Never had to do any installations up to version 8, but 9i was _bleep_, 10g was pretty crap... 10gR2 bearable. 11g was a step in the right direction and 11gR2 not too shabby. Haven't had the time to install 12c yet myself, but the installers for their other (predominantly weblogic) work pretty well when you can get your head around the installation guides, assuming you're doing something non-vanilla. IMNSHO of course.
Oh yeah there was the time I uninstalled a piece of application software with the OUI, and as well as what was expected it deleted 1 library out of another oracle installation. Finding that was LOADS of fun. But that was in the 10g days. If you go with 12c, when they release an upgrade you're supposed to install the new software, unplug your database from the old home and plug it into the new one (aka pluggable databases). I'd wear a little pain with the installer for that feature.
Also not for the faint of heart, the grid infrastructure software which provides the cluster / ASM support weighs in around the ballpark of 1G of RAM usage, before starting up your RDBMS. Not much of an issue when the cost of RAM is such that the average home enthusiast can afford 16G or more of the stuff. But when you use the features (because you need them), it's approximately worth it.
> Flashback queries and flashback archives (they are really cool)
Is that the same as time travel?
Nope, in Oracle you can run this query on any table to view the data it held yesterday:
select * from emp as of timestamp(sysdate-1);
Better still: /* Which employee records did Joe accidentally drop again? */ /* as of right now */); ... to see what you've dropped, and say if you know it was only that table affected then you don't even have to shutdown the database to get it back:
select * from emp as of timestamp(sysdate-1) where empid not in (select empid from emp
insert into emp (---insert above query here---);
At database level it's common before a potentially risky data change to create a flashback point, and if it messes up, shutdown, revert to the time you created the flashback, and pretend the changes never happened. It happens as fast as all the necessary extents can be written back to the data files and the database can be restarted.
But but but ... you are paying for those features. ~$10k per pair of intel cores per year before haggling... if all you want is a rock solid database, Postgres should be at least as good, and at a much lower price.
I've been a relatively mild-mannered open source advocate for over 20 years now, and have been running Linux for all of it. My first DBA job was with Postgres (6 or 7, ~12 years ago now!) and now Oracle. This is all about databases, completely ignoring the application related acquisitions they've made in the last decade...
A lot of difference I see and is evident from the discussions here is that Oracle usually has the features earlier (not always, but yes, usually). The earliest example I've witnessed is Postgres' Write-Ahead Logging, which was definitely cool, but Oracle were there first. More recently, with 11gR2 you have advanced compression (pay $$$$ and it will store all your data compressed if you want) and with 12c there are a bunch of features that make me drool. Pluggable databases is just one of them.
Again, not entirely sure about Postgres, but Oracle build a lot of instrumentation into the database software itself. Tracing custom events is a great way of profiling your application as well as database deficiencies. Pay for the license to unlock the full power of ASH or AWR and you have a great deal of ability to see exactly what's going on and figure out how best to resolve any performance issues. The best bit is that this instrumentation doesn't make the database run like a dog. A few percent overhead gives you a lot of debugging power, and it's ALWAYS turned on with basic event tracking always happening anyway. But you can add MOAR.
I see some impressive performance on Oracle databases these days, but not entirely convinced that Postgres cannot meet them. But then, Oracle can run on anything from 32 bit x86 to some seriously beefy hardware (and when it does, it runs well). I'm not entirely sure about Postgres, but I know Oracle has been compiled for RISC architecture (Power, SPARC, HPUX, others??) for a long time. These days they to lean towards x86 - and will even sell you a "database machine" (google for Exadata). This extends to scaling out on any of the supported architectures with their cluster software (Grid Infrastructure) these days, which is quite mature now. Again, Postgres probably does this, but each generation sees a significant improvement for Oracle.
Having said all that, leading edge can also be bleeding edge... The biggest problem for me with Oracle continues to be the time it takes to resolve software bugs combined with their support infrastructure. While it usually gets there in the end, for the price you pay for enterprise support one might expect quicker resolution if you happen to be the first person to hit upon a specific problem. Unfortunately this tends to tie with the need to certify with all the Oracle applications they release and support. The one and only bug I reported when I was a Postgres DBA was around a date calculation issue - from the behaviour I reported it was tracked down and patched in ~ 2 days, and I had a workaround for the meantime anyway.
Oracle have also done some cool stuff in the open source domain with OCFS (and now OCFS2) and the free domain with their base GI cluster software, as well as the plain cool domain with ASM (dynamically manageable disk pooling with Stripe And Mirror Everything methodology providing solid data robustness) and ACFS which lets you carve out clustered POSIX compliant filesystems on top of ASM at will. This all helps with scaling (don't need OCFS2 now if you use ACFS tho).
Hmmm, it seems they really are turning me to the dark side.... heeellllllppppp!!!!
... when the laser's mounted on a Frickin' shark's head.
OCFS was originally designed specifically for storing Oracle datafiles, in a cluster, in a non-POSIX fashion. After that came OCFS2, which is POSIX compliant, but can deadlock when NFS exported due to the way NFS handles locking, in a way that can be worked around with the "nodirplus" NFS mount option (not available on all OSes, but Linux is ok). They since developed ASM (Automatic(ed?) Storage Management) which threw away the traditional filesystem presentation of your oracle datafiles, and subequently bundled that into the release of 11gR2 clusterware and extended the functionality to give us ACFS - ASM Clustered Filesystem.
11gR2 clusterware is designed to be clustered with shared storage, and depending on the options when created will happily give you a POSIX compliant clustered filesystem for any occasion - datafiles, regular files - whatever. It is Oracle's implementation of their "best practice" Stripe And Mirror Everything methodology with the aim of not only high availability, but consistently high performance, through spreading all your data across all your disks, and implementing mirroring in a sane way too (split your disks into two (or three!) failure groups, and the software will ensure there are 2 (or 3!) copies of each block. All you do is add disks to the pool(s), and if you have the space you can dynamically remove disks from the pool too. You can fsck, mkfs, mount and unmount it, take snapshots (!), and the lead-up to all that is all not much of a stretch from LVM. Google for Oracle ACFS and see the "Basic Steps to Manage Oracle ACFS Systems" section.
OCFS was only ever available for Linux, but ACFS now supports other platforms... probably doesn't matter to you. The one catch I've found so far is the ~1Gb RAM overhead to run the clusterware PER NODE. There's other reasonable stuff, like you need the network layer to be up in order to start the ACFS supporting services, so you can't put anything related to the basic boot process on those volumes.
The cost of 11gR2 clusterware? ... nothing. I think it's one of very few "free" (as in beer) products they do. It will work on anything they've compiled it for though - generally means your Enterprise OS like RHEL5 (and should be easy to shoehorn onto CentOS), a recent SuSE release, and of course their own Oracle Enterprise Linux - which I believe is also free to use, but pay through the nose if you want them to support your implementation. Remember that this system is the platform for some very expensive Oracle products, but at the same time it is perhaps a younger product than some you'll have already looked at.
As for the fencing method, it all works via heartbeat to disks in your ACFS pool. If the clusterware can't "ping" the disk within the threshold, it forces the system that's having the issue to reboot. Such is the nature of ensuring sanity when using shared disk. I suggest looking at it if your boxen can spare the RAM and you're happy to accept their OTN license agreement, as it really does seem to be one of Oracle's better products at an amazing price for what you get.
All fine, except if the system isn't for Oracle products then the vendor supporting the app will look at you funny when you tell them what enterprise OS you're running on.
RHEL has a certification relationship with many vendors. OVM, CentOS, and even to some degree Fedora, while being very similar as far as the administrator is concerned, are completely different when it comes to what level of supportability you'll get. At least 2 of those won't be particularly interested.
Of course, if you're supporting your own custom application then the answer is to run whatever OS you're comfortable with. If you want RedHat to look as a matter of priority at a technical problem you're having that is say related to their kernel, you'll have to pay them the license fee for that level of support. If your CIO wants a vendor to take some accountability, it has to cost something...
Then there are the certain applications that check the contents of your /etc/redhat-release file, and if they aren't happy with the answer, they'll refuse to go on. Of course, that's only a text file that any superuser can create. :)
Nobody really bothers with reporting good news (great news, yes, good news doesn't sell). Bad news of any kind loves to spin. If the radiation levels vary significantly over even the next week (this must include going down) then there are no dangerous radioactive materials involved - such things have significantly higher half lives than seconds, minutes, or hours... even days.
Despite the explosions, this "disaster" is still officially at least 1 level lower than TMI ever was, and that was more bark than bite. No meltdown. Some heavy-ish elements in the reactor may be somewhat dangerous to get close to for a while, and if they escape they will be of mild concern because they can't sustain a reaction like you get in a nuclear reactor, whether it be for power (Uranium/Plutonium and other scary stuff) or medicine (not so scary, but still troublesome to carry lumps in your pocket). The half-life of those materials within the reactor will be what determines the time it takes from the control rods being inserted to the reactor going cold (and yes there will be significant residual radiation inside the reactor in normal circumstances). Current temperatures within the reactor simply won't be high enough to vaporize much that could be a threat. It's just better for you not to inhale the stuff that is out there, just as it's better for you not to inhale cigarette smoke.
Secondly, think beyond the narrow-minded figure that "minutes" means no more than 10 minutes...
Say the half life of the radioactive gasses escaping the power station is 30 minutes. yes, 30. It's not unthinkable. In that case 400 millisieverts (reported to be an exposure at the reactor) becomes 25 millisieverts after 2 hours, or ~1.5 millisieverts after 4 hours, or somewhere in the region of reported levels in Tokyo after 5 hours or so. Is a 50km/h sea breeze enough for you in a tropical region? This means the radioactive material in the atmosphere is decaying fast enough not to pose a significant health issue. If there is enough exposure to worry about, people start taking iodine pills. Sure, iodine pills have even been distributed around the area, but how many have actually been taken so far? Possibly that one exposed worker, and whoever decided to panic. Yes, we're still quite peachy. Conventional fuel based explosions have happened at a nuclear power plant, because a byproduct of the residual reaction is an ideal, carbon-free, fuel (H2), and it ignited. When the reactor shutdowns, which have been hampered by the problems at the plant, complete, then the properly protected experts can have a look and the full story on how much dangerous nuclear matter has been released into the atmosphere will come out. I think you'll find it's negligible. The Japanese should be worrying about other things than the potential for a nuclear holocaust.
Generally the most dangerous nuclear material is that with a half life comparable to the lifespan of a human, ie decades. Yes there are spikes of radiation, but they dissipate quickly. 23 times the normal levels? I receive a day's worth of background radiation in an hour... as long as that doesn't happen for a month it's not likely to affect my health.
The real problem is if the nuclear fuel escapes into the atmosphere - that's where you end up with clouds that are dangerous. It hasn't happened in Japan yet, despite the physical assault the earth has thrown at it. Radioactive gases have been vented, and are short lived, and low risk because it's total exposure to radiation that causes the real health issues.
So far I still only see reports of one worker exposed to levels of radiation that are equivalent to a few years worth of radiation in an hour. That person may get cancer, and has every right to be worried, but you can get cancer from inhaling coal dust too. Or smoking, or, depending on what the media wants to pick up and run with, eating potatoes, or breathing. The point is, don't believe the hype that the media is using to sell stories. They don't seem to know what they're talking about. As soon as someone admits "radiation leak" the media broadcasts "Chernobyl" and the average Joe starts overreacting. These stories are alarmist, pure and simple, and it's selling newspapers and online advertising, while at the same time putting enough fear into people to affect the rescue and recovery efforts from the natural disaster.
I were in Tokyo I'd keep an eye out for any official reports about a genuine containment failure, while continuing to live my life.
Oh yes, those who use this as a tool to fear nuclear power need also to remember that this is a 40 year old plant, and there is new technology in such things which prevents the chance of even a partial meltdown, period. Very clever stuff where the fuel is embedded in material that expands as it gets too hot, which effectively moderates the fission reaction and prevents it going past a certain point.
*cough*Hindenburg*cough* :)
Thousands were dead in minutes, and people seem to be insinuating that a fatality and some injuries after the natural disasters are beyond what might be considered statistically normal. Accidents happen, however unfortunate they may be.
The reason for the explosions is due to the knowledge that the hydrogen/oxygen gas mix released would be marginally radioactive with a half life measured in seconds, and the intent was to contain the gas for long enough for it to be rendered inert. The risk of explosion was acknowledged, people were warned, and when when it did blow, well they had had opportunity to move people further away than they were. The escaping gases ARE raising radiation levels ... a bit. However, I think you'll find the radiation doses astronauts get are higher than those the bunnies outside the fences of the nuclear power plants are getting.
It takes a few days for a reactor that has had the control rods slammed into the shutdown position to cool down, and in the meantime the generator still generates some heat and needs some cooling. When the backups and backups of backups failed, they chose the less desirable route, in pumping in sea water. As it ain't pure water, you end up with slightly more radioactive matter with a half-life which is more like minutes than seconds, so less desirable, somewhat radioactive gas results, which is harmless well before it travels that 30km. There will be no noteworthy radioactive residue when the cool down is complete, except for what's in the reactor itself.
The reactor everyone's jumping up and down about has survived an earthquake and tsunami well beyond design spec, and as for the inconvenience of lost power. Yes, they lost backup and backup backup diesel generators, but they also had battery backups which held until mobile generators could be moved in. I also dare anyone to tell me what power generation scheme in that location at that time would not have failed, so of course there will be power rationing and/or blackouts.
The Japanese got the sum of their design and processes of their nuclear reactors right, and they are taking every precaution they can to ensure public safety. The biggest mistake was trying to contain the gas from the reactor instead of venting to the atmosphere, because the media are making it look like these gas explosions might be a sign that a meltdown is imminent. It isn't, but the media never let facts get in the way of a good story. Those responsible for the reactors are simply Doing The Right Thing [TM].
Based on what Mr Atkinson has alleged in the past, it's far more likely that what actually happened was a gamer slipped him an e-mail that said something along the lines of "I'm 19 now and you have to let me see b00bs in a game if I want! Otherwise if you ever show up in <Online FPS>, me and my buddies are going to camp all the spawn points and frag you 'til you cry to your mum!"
1) Donot turn on swap.
2) If there's ever any problem with memory, create a swap file (if you don't have one yet) and type swapon on a live system.
1) is not the best idea, at least for Linux. One of the things the Linux kernel can effectively use swap for is defragmenting memory! Swap a chunk of memory out to disk, and read it back in at a more suitable location. A long-running, hard working kernel will reward you even for a measly 256M swap partition - eventually.
2) Swap files are significantly slower than swap devices. Consider this: Your swap file lives on a filesystem. Your system decides it's struggling with memory and begins trying to swap some cached files out (it may assume that swapping them out and back in again is faster than re-reading off the original disk)... potentially onto the same disk the originals come from, causing more thrashing. It may even have to consider whether it can to swap out bits of the swap file! Plus you're dealing with filesystem layers which will only slow down the process... so give it at least one device/partition as a priority, and add swap files with a lower priority for temporary/emergency purposes only, if you care about performance.
The amount of swap any system requires is very situation/application dependent. If your system isn't using swap much at all, then good for you! Don't throw a lot of swap at it! But be nice to your Linux kernel, and give it something to use for its own sanity.
I don't mind taking the risk, as it's not like losing a few ccs of blood every year or so will be a problem. It's just fun to note how vicious those $!@^#!s can be. It doesn't have to be a big slip to get yourself sliced open, and I swear the cases resent the fact that they're going to have to get along with the new motherboard so they go out of their way to ensure the slip is big enough!
What the heck, typical box I would have assembled for a friend last year:
- ~Intel P4 3GHz (these days I would as likely choose AMD)
- ASUS mainboard - usually Deluxe but without onboard graphics, 1Gb network card. Onboard sound is fine (5.1 is more than these friends are likely to use
:)
- The current $100-200 graphics card, 128Mb - NVidia or ATI depending on who's just dropped their prices.
- Minimum 80Gb hard drive.
- One extra case fan - preferably not Neon
- 2x512Mb RAM to suit the mainboard. Would have been DDR2 I guess.
- A Liteon or other standard DVD burner, probably 8x.
- Microsoft Keyboard/Mouse OEM package. NOT wireless. Batteries, bleah!
- Standard Sony floppy drive
- Surge protector or UPS according to budget and value of their data
- Monitor according to budget - reasonable response LCD or larger CRT.
- $30 speakers. If they want immersion then they can use headphones
:p
- I would have also ensured they got an OEM copy of XP Home, and set up Firefox/Thunderbird/AVG at the very least.
I wouldn't say they're experienced gamers at all, but have had no complaints apart from a couple of dodgy power supplies - one the shop was happy to replace, the other was just mine and a little out of warranty.Doesn't need to be running... every single time I've done assembly or reassembly involving a new motherboard, the case has drawn blood. A little matter of needing to use a little force to get something to snap into place... and it gives more suddenly than expected. About half the time has required a band-aid to prevent getting blood everywhere. I guess that's the main downside of many cheaper cases - sharper edges!
Craft like the stealth bomber work by scattering radar signals so they return almost any which way but back to the sender, making them appear a lot smaller than they really are. If there were something in the shadow of its profile, you wouldn't see that either. You would get no significant "ping" from your radar signal.
This theory, if it works and proves practical, would change things so you would get no reflection off the bomber, but you would see the object behind it just the same as if the craft wasn't there. There would be a radar blip! The downside for the bomber is if the object behind was a legitimate target, the bomber would be hit by shots aimed at the object behind.
It sounds like any effective cloak created using this any time in the "near" future would only really be effective for static installations.
That's when you should be able to sit through an interview and easily convince a potential employer that even if you don't know the semantics of language X, you'll know the basics in 24 hours and by the time you start work the following Monday you're basically fluent in it. Better still, when you apply for the job, learn at least the basics of the language before the interview. Just remember that a) your style of approach to a solution is often just as important as your general knowledge of the technology and b) all bullshit will get you in a smart workplace is unemployed again 2 weeks later.
- Whether the object is orbiting something else
- The size of the object
- The amount of work required to escape the object's gravity well - whether to escape altogether, or get into the partner object's gravity well.
Of course, the easiest way to set boundaries for these involves some kind of galactic pogo stick to determine whether you can jump from one object to the next.