Дядьки, а помочь слабо?

[AgentXXX 1]

Уже давно известно, ум хорошо - а два хуже.

Спецов навалом, глядишь - кто чего умное скажет.

SUBJ

Хотелось бы утянуть без всяких дампов и прочей офф-лайновой хрени.

Может кто без взгляда на конкретную Ораклину скажет, может можно какие опции навесить на выполняемый запрос, чтобы утянуть дата?

Проблема в том, что Оракл в состоянии медленной предагонийной хрипоты.Работает как ...ц медленно.Бедняге индексы рефрешали ещё в 2006 году.Статистики там тоже плакали.(железо соответственно, до исторического материализЬму сделанное)

Может трабл именно в этом порылся?Оно бы радо отдало данные, да не успевает?Ась?

[Jin 0]

про оракл не скажу потому как попроще и поменьше юзаю...

но нахожусь под столом

SELECT

NUMERO_SECUENCIA as LUG_FU_ID

,NUMERO_EXPEDIENTE as LUG_FILENUM

,FEC_CREACION as LUG_FU_DATE

,ORIGEN as LUG_FU_TYPE

,TEXTO as LUG_FU_DESC

,NVL(INFOR_EXTERNA,0) as LUG_FU_ASSOCIATION

,NVL(EXTENSION_ASOCIADA,0) as LUG_FU_EXT_NUM

,FECHA_ACTUALIZACION as LUG_FU_ACTUALDATE

FROM IBE_SEGUIMIENTO

WHERE FECHA_ACTUALIZACION ...

[tenevoj 0]

FROM IBE_SEGUIMIENTO

WHERE FECHA_ACTUALIZACION

 

Me gusto (a)!

[Jin 0]

PS: из опыта попроще, дамп самая надежная вещь.

25.12 в час X проводочек их сети вытащи и все слей

[AgentXXX 1]

попроще, дамп

Ме не ищем лёгких путЁв.

Понравилась вам "шпанелщина"?Гы!

У меня такого много, всё на испанском и никакой доки.Классно?

[tenevoj 0]

Entendo!!

[Jin 0]

зато можно совершенствоваться

[vladiSib 237]

у меня подобная хрюшка была на немецком. поля под названием BenutzerGruppen как правило вводили новичков в ступор.

[younghacker 7]

Я не шарю в оракле, и чё там по ссылке написано?

Он не способен вытолкнуть данные из одной таблицы в другую таблицу?

А таблицы внешние в другом файле у него бывают?

А бэкапы "на лету" он умеет делать? Может через бэкап?

А вытянуть кусками? Отсортировать по первичному ключу, и рвать кусками.

[alp 0]

Oracle Heterogeneous Services

[ArjLover 0]

В лоб эту задачу не решить. Но ты далеко не одинок с такой проблемой - существуют масса решений для бэкапирования и дампирования таких таблиц. Но ни одно из них не наложить сверху на работающую базу. Их надо подкладывать снизу под фундамент.

[Archer 1623]

Если таблица выполняет роль лога, то получается, что старые записи не апдейтятся. Вот их и сливать в первую очередь. А вообще логи архивировать надо вовремя...

[Yevgen35 0]

Я уже тебе говорил неодноктратно.

У вас в конторе организационная проблема, которую надо решать.

Она на уровне SQL нифига не решается.

Поэтому и помочь тебе тут никто не сможет, кроме твоего босса.

А ты все как Александр Матросов с одной гранатой пытаешься лезть на амбразуру.

 

ИМХО:

Не делай этого.

Поставил бы своего босса перед фактом, что это надо,

а он уж пусть разруливает отношения между отделами.

 

Одного доступа тебе на уровне SELECT явно недостаточно.

А без доступа можно только курить траву.

 

Практически уверен,

что после переноса вашей апликухи у вас через какое-то время будут

теже самые проблемы с MS SQL-ем.

 

Если таблица выполняет роль лога, то получается, что старые записи не апдейтятся.

У него там не совсем лог.

Точнее совсем не лог, а обычная таблица фактов.

[alp 0]

Живенько себе так представил систему 24/7/365 в состоянии медленной предагонийной хрипоты...

Рядом не страшно? Она ж бахнет када-нить...

[AgentXXX 1]

В лоб эту задачу не решить.

Решаю подобные проблемы.Дорого!

Посколько вопрос производительности не стоял - решил это курсором.

1,5 млн в час сосёт.

Все 3 раза Ку.

Спасибо всем за виртуальный брейн-штурм.