Results 1 to 6 of 6
  1. #1
    Join Date
    Jan 2004
    Location
    california
    Posts
    37

    Unanswered: ora -01122 need help to reset timestamp on control file

    Kind sirs,

    I was trying to rebuid my control files. I copied my old ones and renamed the original. I used an alter database backup to create the sql for the new control file. and ral the sql. Unfortunatly I recived an 01115 error when running the create control file. So I placed the original control file back and when I trid to do a startup, I received a 01122 and a 01207. I searched the internet but could not find anything specific on how to reset the timestamp.

    Any help on eithor of theses would be appriciated.

    Thanks
    Peter
    Last edited by PDELLIS; 01-18-04 at 16:25.

  2. #2
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    The short answer is to reformat the disk & start over.

    > I was trying to rebuid my control files.
    WHY, was wrong with them?

    Hopefully you've now learned one thing that you should not do again.

  3. #3
    Join Date
    Jan 2004
    Location
    california
    Posts
    37
    I was trying to fix a ORA-01157 Cannot identify/lock data file 3 - see DBWR trace file error. Metalink said to try the rebuild.

  4. #4
    Join Date
    Jan 2004
    Posts
    370
    You start with an ORA-1157 error and end up with your control and datafiles out of sync.
    You are in danger of trashing your database.

    You have had two separate error messages indicating an I/O problem of some sort.

    ORA-01115 IO error reading block from file string (block # string)
    Cause: The device on which the file resides is probably off line.
    Action: Restore access to the device, then retry the operation.

    ORA-01157 cannot identify/lock data file string - see DBWR trace file

    What looks like an underlying Unix issue to me has now developed into an Oracle one, with the initial problem still unresolved.

    Try copying the files reported in these errors to another part of the system using cp - if cp can't read the files then Oracle won't be able to read them either.

  5. #5
    Join Date
    Jan 2004
    Location
    california
    Posts
    37

    THANKS TO ALL

    Hi sky,

    Your last words where 100 % correct. The database is now DEAD .
    I was so close to figuring it out before I killed it, but know the damage is done. Hear is how it went down.

    As of 3 pm the database was still intact. After much suffering, long nights on the computer, 100's of pages of documentation and working with many people and many hours, no one could pinpoint the problem. It this point I decided that I would rebuild the control files. I was desperate. A metalink document said that this could be a cause. I had tried everything, or so I thought.

    When I tried to do the rebuild it failed with an IO error. I figured that maybe the file on the disk was shot so I moved it to another drive, modified the control file and rebuilt it, but that did not work.

    I had always suspected that this had something to do with a Unix parameter or a init.ora setting that had to do with file size. I started to suspect that maybe it had to do with the 2 gig file limitation, but when I checked my file systems they where set for large file.

    On many occasions I had played with the ulimit. I tried to set it to a large number, but it would not take. I had read about unlimited, but when I typed ulimit f unlimited I would receive an error. If I typed a large number it would also give me an error. On Friday a DBA looked at the machine for a few min. She tried to up the ulimit but had the same result.

    This afternoon prior to the databases impending death I tried again to up the ulimit in the users setup, again without success. I set the numbers as high as they woud go without error and began to try my file moving, control file exercise.

    I called two local DBA's yesterday and offered to bring my machine to there house. I offered to pay them whatever they wanted, But my phone stayed silent.

    At about 6 pm I was dead in the water. My database was now out of sync with my control file. But if I could fix the control file issue, I could rebuild the control file and then the database would be in sync again.
    So I did what any potential millionaire would do and "phoned a friend"

    I said Colin could you please come over and help me with this. Now colin is a plsql expert, but has little idea what goes on under the covers. But I needed a fresh look.

    When He arrived I explained that I though it was something to do with a limitation being placed on the system by some setting. I started to go over what I had done and I explained how I could not up the ulimit. I showed him how unlimited did not work. He did not know what ulimit was, but started to sift through some of the many pages of documentation.

    He came across one that showed a fsize = -1. It did not specifically say anything about this -1, but we decided to give it a try and to our surprise, when we did a ulimit -a size was now set to unlimited. So we ran back to our sql script to create our control file and gave it a try.

    I bet you can see where this is going. The rebuild control fileworked like a charm. I knew at this point that I was on the correct path, but was afraid of the impending results of my previous actions.

    Swiftly I started sqlplus and entered the startup command. I waited with baited breath as the system mounted. Yarica ! i figurd it out, but the glory came to an end when the console came back and said DATA FILE CORRUPT PLEASE RESTORE FROM MEDIA.

    I had come so far, and learned so much in the last two weeks, but it was all for loss. So hear I am at 3am building a new database, tablespaces ect. Tomorrow I will start the long recovery process from my data exports. I have close to 200 gig of data and lots of indexes.

    So in closing, I must thank you and all the others who helped me so diligently theses past two weeks. You helpled me more than I can say. And while the outcome was not sweet. I have learned more about ORACLE internals, setups and recovery this week that I have in my 18yrs of programming.

    And of course the moral of the story is MAKSYSB

    Thanks
    Peter

  6. #6
    Join Date
    Jan 2004
    Posts
    84

    Re: THANKS TO ALL

    Hey Peter!
    I would suggest, in future do avoid trying out things on database(especially if it a production one) when you are not sure about it .
    It is always better to log your call with Oracle Support through their official sites who will do their best to restore the normalcy.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •